0% found this document useful (0 votes)
4 views88 pages

Web-Based Exam Management System Proposal

Uploaded by

lastpricemikias
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
4 views88 pages

Web-Based Exam Management System Proposal

Uploaded by

lastpricemikias
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

Mekdela Amba University

Collage of Computing and Informatics


Department of Information Technology
Industrial Project Proposal on
Web-based Exam Management System

Submitted to the Department of Information Technology in partial fulfillment of the


requirement for the degree of Bachelor of Science in Information Technology

Group Members Name Id_No


1 Mikias Tsegaye------------------Mau1401820
2 Abebe Tamir-----------------------Mau1303026
3 Muluken Belay-----------------Mau1602224
4 Mohamed Setew ---------------Mau1401866
5 Wase Mulatu--------------------Mau1405783
6 Hawa Ibrahim------------------- Mau1401337

Advisor: Mr:Habtamu Shiferaw:

March, 2025
Tulu Awuliya, Ethiopia
Approval Sheet/Declaration

This project is developed by us to full fill the requirement of bachelor degree as final year
project in order to graduate. Since the project is the result of our effort someone who will take it
to present as his/her work is totally illegal. But someone can modify and add additional
functions including the future works written at the recommendation with the permission of us.

Student full Name Signature Date


1 Mikias Tsegaye _________________ ________
2 Muhamed Setew _________________ ________
3 Wase Mulatu ___________________ _________
4 Hawa Ibrahim _________________ ________
5 Abebe Tamir _________________ _________
6 Muluken Belay _________________ _________

Collage : Computing and Informatics


Department : Information Technology
Project Title : Web-based Exam Management System
This is to certify that I have read this project and that in my opinion it is fully adequate, in
scope and quality, as a project for the degree of Bachelor of Science.

------------------------------------- ------------------------------------ Date---------------


Name of Advisor Signature

Examining committee members Signature Date

1. Examiner :_____________________________ ____________ ____________


2. Examiner :_____________________________ ____________ ____________
3. Examiner :_____________________________ ____________ ____________
It is approved that this project has been written in compliance with the formatting rules
laid down by the College.

ii
Acknowledgment

First and foremost, I would like to express my deepest gratitude to GOD Almighty for granting
me the strength, wisdom, and perseverance to doing this project. We, the project members of
the Web-Based Exam Management System (WEMS), would like to express our deepest
gratitude to all individuals and institutions whose support and contributions were vital to the
successful completion of this project. Our sincere appreciation is extended to the following:

1. Advisors/Supervisors: We are profoundly thankful to our project advisor Mr Habtamu


Shiferaw for their invaluable guidance, consistent support, and expert supervision
throughout the entire project.
2. Team Members:-Special appreciation goes to each member of our project team for
their dedication, collaboration, and unwavering commitment.
3. Friends and Classmates:-We are also grateful to our friends and classmates for their
encouragement, helpful suggestions, and collaborative spirit during the course of this
project. Your support greatly contributed to our motivation and progress.
4. Family:-Last but certainly not least, we express our deepest gratitude to our beloved
families.

Acronyms

[Link] -----Active Server Pages .NET


CPU--------Central Processing Unit

iii
CRC------- Class-Responsibility-Collaboration
CSS--------Cascading Style Sheet
DFD--------Data Flow Diagrams
HTML------Hypertext Markup Language
HTTPS--------Hypertext Transfer Protocol Secure
MAU-------Mekdela Amba University
MCQ-------Multiple-Choice Questions
PC--------Personal Computer
PDM------ Paper-based Data Management
RBAC-----Role-Based Access Control
SQL--------- Structured Query Language
SRS----------System Requirements Specification
SSL--------- Secure Sockets Layer

UI-----------User Interface
UML--------Unified Modeling Language
URL-------- Uniform Resource Locator
WEMS/WBEMS------Web-based Exam Management System

Executive summary

iv
The Web-based Exam Management System aims to modernize the examination process by
providing a secure, efficient, and user-friendly platform for conducting online assessments. The
goal of this project is to automate exam creation, scheduling, administration, and result
processing, reducing manual workload and errors. To achieve this, the system is developed
using C# or [Link] with SQL, incorporating features like user authentication (admin,
teacher, student), automated grading, real-time monitoring, and performance analytics. A
structured database ensures efficient data storage and retrieval. The expected outcomes include
faster exam administration, instant result generation, enhanced security, and better accessibility
for students and educators. This project is significant as it improves efficiency, minimizes exam
malpractice, and supports remote learning, making it a valuable solution for educational
institutions in the
digital era.

v
Contents
Approval Sheet/Declaration..................................................................................................................ii
Acknowledgment.................................................................................................................................iii
Acronyms.............................................................................................................................................iii
Executive summary..............................................................................................................................iv
List of Tables.........................................................................................................................................ix
List of Figures........................................................................................................................................x
Abstract................................................................................................................................................xi
CHAPTER ONE:..........................................................................................................................................1
1.1 INTRODUCTION...............................................................................................................................1
1.2 Background.....................................................................................................................................1
1.3 Review of Related Work..................................................................................................................2
1.4 Statement of the Problem...............................................................................................................3
1.5 Objectives.......................................................................................................................................4
1.5.1 General Objective:....................................................................................................................4
1.5.2 Specific Objectives....................................................................................................................4
1.6 Methodology...................................................................................................................................4
1.6.1 Requirement Gathering Methods............................................................................................4
1.6.2 Analysis and Design Methodology...........................................................................................5
1.6.3 Implementation Methodology:................................................................................................7
1.7 Scope and Limitation.......................................................................................................................9
1.7.1 Scope.......................................................................................................................................9
1.7.2 Limitations..............................................................................................................................10
1.8 Significance and Beneficiaries.......................................................................................................11
1.9 Time and budget...........................................................................................................................12
Time Schedule.................................................................................................................................12
1.10. Organization of the Project........................................................................................................12
CHAPTER TWO:.......................................................................................................................................12
SYSTEM REQUIREMENT AND SPECIFICATION (SRS)............................................................................12
2.1 Existing System..............................................................................................................................13
2.1.1 Overview................................................................................................................................13
2.1.2 Functionalities of the Existing System....................................................................................14
2.1.3 Business rule..........................................................................................................................16

vi
2.1.4 Drawbacks of the Existing System..........................................................................................17
2.2 Proposed System...........................................................................................................................17
2.2.1 overview.................................................................................................................................17
2.2.2 Functional Requirements.......................................................................................................19
2.2.3 Non-Functional Requirements...............................................................................................21
2.3 Feasibility Study............................................................................................................................22
2.3.1. Operational Feasibility..........................................................................................................23
2.3.2. Technical Feasibility:.............................................................................................................23
2.3.3. Economic Feasibility:.............................................................................................................23
CHAPTER THREE: SYSTEM MODELING....................................................................................................24
3.1 Use Case Model.............................................................................................................................25
3.1.1 System use case documentation............................................................................................29
3.1.2 Use case Description..............................................................................................................30
3.2 Conceptual Modeling(Analysis Level Class Diagram).....................................................................37
3.3 Key Abstraction with CRC Analysis................................................................................................38
3.4 Object Diagram.............................................................................................................................39
3.5 Dynamic Model.............................................................................................................................40
3.5.1 Sequence diagram.................................................................................................................40
3.5.2 Activity Diagram.....................................................................................................................45
3.5.3 State Chart Diagram...............................................................................................................49
3.5.4 User Interface Prototype........................................................................................................54
CHAPTER FOUR: SYSTEM DESIGN...........................................................................................................54
4.1. Introduction.................................................................................................................................54
4.1.1. Overview of System Design Goal...........................................................................................55
4.1.2. Design Goals..........................................................................................................................56
4.2. Detailed Class Model....................................................................................................................58
4.3. Current Software Architecture.....................................................................................................59
4.4. Sub-System Decomposition with Services....................................................................................60
4.5. Proposed System Architecture.....................................................................................................61
4.6. Component Diagram....................................................................................................................62
4.7. Deployment Diagram (Hardware / Software Mapping)...............................................................63
4.8. Persistence Model........................................................................................................................64
4.9. Access Control and Security.........................................................................................................65

vii
4.10. Global Control Flow....................................................................................................................67
4.10.1. Procedural-Driven Control Flow..........................................................................................67
4.10.2. Event-Driven Control Flow..................................................................................................67
4.11. Boundary Conditions and Exception Handling...........................................................................68
4.11.1. Boundary Conditions...........................................................................................................68
4.11.2. Exception Handling..............................................................................................................69
4.12. User Interface Design.................................................................................................................70
References..........................................................................................................................................77

viii
List of Tables

Table 1. 1 Implementation Methodology..................................................................................................8


Table 1. 2 Time Schedule........................................................................................................................12

Table 2. 1 Instructor Record Scores of Students.....................................................................................15


Table 2. 2 Attendance of the Students.....................................................................................................16
Table 2. 3 Business Rules.......................................................................................................................16
Table 2. 4 Draw back of existing System................................................................................................17
Table 2. 5 Role-Based Access Control....................................................................................................19
Table 2. 6 Functional Requirement.........................................................................................................21
Table 2. 7 Non-Functional Requirement.................................................................................................22
Table 2. 8 Feasibility Area/ Study...........................................................................................................24

Table 3. 1 Use case and there Description..............................................................................................26


Table 3. 2 System Use Case Documentation...........................................................................................29
Table 3. 3 Use Case Description for Manage User..................................................................................30
Table 3. 4 Use Case Description for Manage Department......................................................................31
Table 3. 5 Use Case Description for Manage Examination.....................................................................33
Table 3. 6 Use Case Description for View Student Result......................................................................34
Table 3. 7 Use Case Description for Take Exam.....................................................................................35
Table 3. 8 Use Case Description for Check Exam..................................................................................36

Table 4. 1 Use Case or Fuctionality for Actor.........................................................................................65


Table 4. 2 Boundary Type.......................................................................................................................67
Table 4. 3 Types of Exception................................................................................................................68

ix
List of Figures

Figure 3. 1 Use Case of the System.........................................................................................................29


Figure 3. 2 Class Diagram for WBEMS..................................................................................................38
Figure 3. 3 CRC Cards for WBEMS.......................................................................................................39
Figure 3. 4 Object Diagram for WBEMS...............................................................................................40
Figure 3. 5 Sequence Diagram for Login................................................................................................41
Figure 3. 6 Sequence Diagram for Manage User...................................................................................42
Figure 3. 7 Sequence Diagram for Manage Department........................................................................43
Figure 3. 8 Sequence Diagram for Take Exam.......................................................................................44
Figure 3. 9 Sequence Diagram for View Result.....................................................................................45
Figure 3. 10 Activity Diagram for Login................................................................................................46
Figure 3. 11 Sequence Diagram for Admin............................................................................................47
Figure 3. 12 Sequence Diagram for Instructor.......................................................................................48
Figure 3. 13 Sequence Diagram for Student...........................................................................................49
Figure 3. 14 State Chart Diagram for Login............................................................................................50
Figure 3. 15 State Chart Diagram for Take Exam...................................................................................51
Figure 3. 16 State Chart Diagram for Manage Exam Schedule...............................................................52
Figure 3. 17 State Chart Diagram for Check Exam.................................................................................53
Figure 3. 18 User Interface Prototype for WBEMS................................................................................54

Figure 4. 0-1 Class model for WBEMS..................................................................................................59


Figure 4. 0-2 Sub-System Decomposition Diagram for WBEMS..........................................................60
Figure 4. 0-3 System Architecture Diagram for WBEMS.......................................................................61
Figure 4. 0-4 Component Diagram for WBEMS.....................................................................................62
Figure 4. 0-5 Deployment Modeling for WBEMS..................................................................................63
Figure 4. 0-6 Persistence Modeling for WBEMS....................................................................................64
Figure 4. 0-7 User Interface for Login....................................................................................................70
Figure 4. 0-8 User Interface for Manage User.........................................................................................71
Figure 4. 0-9 User Interface for Manage course......................................................................................72
Figure 4. 0-10 User Interface for take exam..........................................................................................73
Figure 4. 0-11 User Interface for view result..........................................................................................74
Figure 4. 0-12 User Interface for Check exam........................................................................................75

x
Abstract

The primary objective of this project is to develop a Web-Based Exam Management


System(WBEMS) that streamlines the process of managing academic examinations through a
centralized and automated platform. Manual exam handling methods are often time-consuming,
prone to errors, and inefficient. This system aims to enhance the reliability, security, and
efficiency of exam-related operations within educational institutions. To achieve this, the
system was developed using [Link] for the web interface and SQL Server for database
management. The methodology followed was based on the Agile software development
approach, allowing for incremental progress, continuous testing, and regular feedback. The
system is designed to accommodate various users such as admin, department head,
examCommittee, instructors, and students, with role-based access control. Core features
include student registration, exam scheduling, question paper management, and result
publication. Upon implementation, the system demonstrated substantial improvements in the
accuracy and speed of managing exams. Tasks that previously required extensive manual
effort, such as scheduling and grading, were automated, resulting in reduced workload for
academic staff. Furthermore, the system improved transparency and provided real-time access
to exam data for authorized users. In conclusion, the Web-Based Exam Management System
effectively modernizes traditional exam processes by offering a secure, scalable, and user-
friendly digital solution.

xi
CHAPTER ONE:

1.1 INTRODUCTION

The purpose of Mekdela Amba University's Web-Based Exam Management System is to


automate and simplify the exam administration procedure in educational institutions. This system
will give students a digital platform to take tests and view their results, as well as a digital
platform for professors to design, administer, and assess exams. Through the utilization of
technology, this system will decrease manual labor, boost productivity, and offer administrators
and students a safe atmosphere.

1.2 Background

The Web-based Exam Management System (WEMS) for Mekdela Amba University is an
innovative software solution designed to transform the traditional examination process by
leveraging modern technology. As the demand for efficient and secure online assessments
increases, this system aims to address the challenges faced by educational institutions in
managing exams. The Web-based Exam Management System provides a comprehensive digital
platform that allows for the seamless administration of exams, enhancing both the student and
administrator experience. In traditional examination setups, challenges such as logistical issues,
time constraints, and manual grading processes often lead to inefficiencies and errors. WEMS
addresses these challenges by offering a centralized system that automates key aspects of exam
management, including the creation, scheduling, and grading of exams. This system is designed
to reduce the administrative burden, speed up the evaluation process, and eliminate human
errors, making the examination process more reliable and transparent. The background of this
project is rooted in the increasing need for digital solutions in the academic world, where
educational institutions are embracing technology to improve administrative processes. Mekdela
Amba University, like many others, faces the need to adapt to modern methods of conducting
exams that are more aligned with current technological advancements. The Web-based Exam
Management System is the university’s response to these needs, aiming to improve exam
security, efficiency, and accessibility.

1
This system provides a flexible and scalable solution that can accommodate the varying needs of
different academic programs, allowing for both small-scale quizzes and large-scale university
exams. It also supports remote access, which is particularly crucial in today’s education
landscape, where students may be located in different geographic locations or face mobility
restrictions. By offering a secure, accessible, and automated system, WEMS aims to enhance the
exam-taking experience for both students and exam administrators, ensuring that exams are
conducted smoothly, securely, and fairly.[1]

1.3 Review of Related Work

The implementation of web-based Exam Management Systems (WEMS) across Ethiopian


universities has gained significant traction, driven by the need to improve the efficiency,
security, and accessibility of the examination process. By transitioning from traditional paper-
based exams to digital platforms, universities in Ethiopia aim to enhance the overall examination
experience for both administrators and students. The primary objectives of these systems include
improving exam efficiency, ensuring security and integrity, saving time and costs, enhancing
student performance monitoring, and supporting large-scale exam conduct.

Several universities in Ethiopia have made notable progress in developing and implementing
such systems:

 Ambo University: Ambo University has implemented a web-based examination system aimed at
streamlining the examination process.[2]
 Jimma University: Jimma University developed an online examination system to facilitate
evaluations for distance education students.[3]
 Haramaya University: Haramaya University successfully conducted online midterm
examinations for over 3,200 first-year students.[4]

2
 Bule Hora University: Bule Hora University undertook a project focused on developing an
online examination system to minimize manpower requirements and reduce paper usage.[5]

1.4 Statement of the Problem

Educational institutions worldwide, including Mekdela Amba University, face significant


challenges in managing examinations efficiently and securely. The traditional paper-based exam
system, while widely used, presents a series of obstacles that hinder the smooth administration of
assessments. These challenges include:

 Manual Exam Management: The process of preparing, distributing, and managing paper-based
exams is labor-intensive and prone to human error. This results in unnecessary delays, increased
administrative workload, and potential mistakes that affect the accuracy and fairness of the exam
process.
 Limited Accessibility and Flexibility: Traditional exams require students to be physically
present at designated exam centers, limiting access for students who may face geographical,
physical, or other constraints. This lack of flexibility restricts the ability to offer exams to a
broader range of students, including those enrolled in distance education programs.
 Inefficient and Error-Prone Grading: The manual grading process is not only time-consuming
but also susceptible to errors, which can lead to inaccurate results and delayed feedback. This
inefficiency reduces the ability of instructors and administrators to provide timely and reliable
assessments.
 Security Concerns: Paper-based exams are vulnerable to theft, tampering, or misplacement,
leading to concerns about the integrity and confidentiality of exam content and results. The
physical handling of exam papers increases the risk of unauthorized access and potential
manipulation of exam data.

To address these challenges, the Web-based Exam Management System (WEMS) for
Mekdela Amba University is being developed. This system will automate the entire exam
process—from exam creation and distribution to grading and result management—thereby
reducing administrative workload and human error. By shifting to an online platform, WEMS

3
will improve exam accessibility, security, and efficiency, providing a more reliable and flexible
solution for both students and administrators.

1.5 Objectives

1.5.1 General Objective:

The general objectives of this project is to develop Web-based Exam Management


System for Mekdela Amba University.

1.5.2 Specific Objectives

The specific objectives of the Web-Based Exam Management System (WBEMS) are designed to
guide the development and implementation process, ensuring that each component of the system
aligns with institutional needs and technological standards. These objectives are derived from the
general objective and serve as detailed, measurable outcomes that collectively contribute to the
successful delivery of a secure, scalable, and efficient online examination platform.

 Identify the problems of the existing system.


 Build a new interface design for the proposed system.
 Design a particular model of this proposed system.
 Implement the proposed system in an efficient way
 Build a new database design for the proposed system.
 Collect the information about the existing system.
 Deploy the system and test it till it fits the needs of the organization. if necessary

1.6 Methodology

1.6.1 Requirement Gathering Methods

4
The information required for the development of the Web-based Exam Management System for
Mekdela Amba University (MAU) was gathered using several methods to ensure comprehensive
understanding of the needs and challenges faced by users. These methods helped in collecting
relevant data from all stakeholders involved in the exam process. The following approaches were
employed:

 Interviews: Interviews were conducted with key stakeholders, including teachers, students, and
administrators. These interviews allowed for in-depth discussions regarding their experiences,
pain points, and expectations from the system. The feedback provided valuable insights into the
practical challenges of the current exam management process and the features required to
address them.
 Questionary: A series of surveys were distributed to a wider audience, including faculty
members, students, and administrative staff, to gather detailed information on their preferences
and needs. The surveys helped identify common issues faced by users and their expectations
from an online exam system. By using a questionnaire format, we were able to collect a large
volume of responses, offering a broad view of the requirements from different user perspectives.
 Observation: Observations of the current exam processes were carried out to better understand
the existing system's limitations and inefficiencies. This method allowed us to identify specific
pain points, such as delays in exam administration, manual grading challenges, and logistical
issues. Observing how exams were conducted in real-time helped uncover aspects of the process
that might not have been fully captured through interviews or surveys.
 Document Analysis: Existing documentation and systems used by Mekdela Amba University
for exam management were thoroughly reviewed. This included studying previous records, exam
schedules, grading policies, and any current digital tools in use. Analyzing this documentation
provided a clearer picture of the administrative procedures and technical infrastructure already in
place, which was essential for ensuring compatibility with the new system and avoiding
duplication of effort.

1.6.2 Analysis and Design Methodology

The analysis and design methodology for the Web-based Exam Management System (WEMS)
was carefully chosen to ensure that the system would meet the functional, non-functional, and

5
technical requirements gathered from stakeholders. The following steps were followed to ensure
a structured and efficient design and development process:

 System Requirements Specification (SRS): The first step involved gathering and documenting
all the functional and non-functional requirements of the system. This process was based on the
feedback and input received from various stakeholders, including administrators, teachers, and
students. The functional requirements outlined the core functionalities the system must perform,
such as exam creation, grading, result generation, and security features. Non-functional
requirements addressed performance, security, scalability, and usability aspects, ensuring that the
system would be both effective and efficient. The SRS document served as a detailed reference
point for the entire development process.
 Use Case Diagrams: To better understand the interactions between the system and its users, use
case diagrams were created. These diagrams identified the primary roles in the system—namely,
the Admin, Instructor, Exam Committe, Department Head and Student—and depicted their
interactions with the system. Each use case diagram outlined the main actions or processes that
each role could perform, such as creating exams, taking exams, and viewing results. This helped
clarify the system's functionality from the perspective of each user type, ensuring that all
necessary actions were captured and understood.
 Object-Oriented Analysis: During the analysis phase, our team employed object-oriented
analysis techniques to model the system’s functional requirements. This included use case
modeling to capture the interactions between users and the system in a detailed and organized
manner. We also identified key business objects, such as Exam, Question, Result, and User, and
modeled the relationships between these objects. The goal was to ensure that all the necessary
objects were identified and their interactions defined clearly. This phase also involved a detailed
analysis of the behavior of these objects to ensure that the system would work as intended.
 Object-Oriented Design: Building upon the object-oriented analysis, the design phase involved
using tools like Edrawmax or [Link] to further refine the use case models and design various
system diagrams. This included:
o Class Diagrams: To represent the structure of the system, defining the different classes, their
attributes, and methods.

6
o Sequence Diagrams: To illustrate how objects interact with each other over time to complete
specific tasks or processes.
o Collaboration Diagrams: To show how objects communicate and collaborate with each other to
perform system operations.
o Activity Diagrams: To model the flow of activities within the system, detailing the processes
and decision points.
o State Diagrams: To depict the different states that an object or system can be in during its
lifecycle, as well as the transitions between these states.

These diagrams allowed the team to visualize and refine the behavior, interactions, and structure
of the system, ensuring that all components worked cohesively to support the functional
requirements.

 Data Flow Diagrams (DFD): Data flow diagrams were created to represent how data moves
within the system. The DFDs illustrated the flow of information from the user interface to the
backend database and vice versa.
 Database Design: The database design phase focused on creating a comprehensive schema to
store critical data, such as user information, exam details, questions, and results.

1.6.3 Implementation Methodology:

The implementation phase of the Web-Based Exam Management System (WBEMS) involves
the practical development of the system components using appropriate technologies and tools.
The development process followed a modular approachs, ensuring that each part of the system
such as user interfaces, business logic, database interactions, and report generation was handled
independently but cohesively integrated.

The selected tools and technologies reflect the project’s needs for reliability, efficiency, and
future scalability. The development team utilized both software and hardware tools to ensure
smooth implementation, testing, and deployment of the system.

7
Table 1. 1 Implementation Methodology

No Tools/technology Purpose/activity
1 Visual studio Used for frontend web development
code
2 C# Programming language used to implement server-side logic
3 [Link] Used for backend web development
4 SQL Used to manage and design the relational database for storing data
5 Microsoft Word Used to write the documentation of the system
6 Microsoft Used for preparing and delivering project presentation
PowerPoint
7 Google Used for testing and running the web application during development
chrome(web
browser)
8 Laptop/desktop used for coding, testing
computers
9 Flash disk(8gb- Used to store backend copies of the project and documentation files
32gb) temporarly
10 Paper,printer, Used for different purpose
data cable,
pen/pencil

8
1.7 Scope and Limitation

1.7.1 Scope

The Web-based Exam Management System (WEMS) is being developed specifically for
Mekdela Amba University (MAU) to address the challenges of traditional paper-based exam
systems and to introduce a streamlined, secure, and efficient digital solution for managing
exams. The system will facilitate the entire exam process, from registration and scheduling to
exam creation, grading, and result generation, offering a comprehensive platform that enhances
the overall examination experience for both administrators and students.

The scope of the WEMS for MAU includes the development of an integrated web-based system
that will support the following key functionalities and services:

1. User Registration and Authentication: The system will allow various users such as students,
instructors, and administrators to create and register accounts securely. Users will have the
ability to log in and access their personalized dashboards. The system will implement robust
authentication mechanisms (e.g., username/password, two-factor authentication) to ensure the
security and privacy of user data, allowing only authorized individuals to access sensitive
information.
2. Exam Creation and Management: The system will enable instructors to create and manage
exams seamlessly. setting time limits, and organizing question banks for future use. Instructors
will be able to schedule exams, define rules for each assessment (e.g., randomizing questions,
limiting attempts), and manage exam logistics such as start and end times.
3. Test Taking: The system will provide an intuitive interface for students and participants to
access and take their exams remotely. Students will be able to start exams at designated times,
navigate through questions, and submit their responses directly through the system. The platform
will support various question formats, including objective (multiple choice, true/false, marching).
It will also offer features such as auto-save and progress tracking to ensure a smooth exam
experience.
4. Grading and Result Generation: The system will provide automated grading capabilities for
objective-type questions (multiple choice, true/false, matching), ensuring rapid and accurate

9
results. The system will generate detailed result reports, including scores, grades, and
performance analytics, which can be accessed by both students and instructors. Additionally,
results will be stored securely in the database for future reference and record-keeping.
5. Reporting and Analytics: The system will feature tools for generating reports on student
performance, exam statistics, and overall trends. Instructors and administrators will be able to
track performance metrics such as average scores, question difficulty, and pass rates. These
reports will help in identifying areas where students may need additional support and in
improving future exam planning.
6. Security and Data Privacy: Security will be a major priority for the system. Measures will be
implemented to protect the confidentiality and integrity of both exam content and user data. This
includes secure login, data encryption, and measures to prevent cheating, such as randomization
of questions and automatic monitoring during exam sessions.
7. Scalability and Flexibility: The system will be designed to handle a wide range of exams, from
small quizzes to large-scale exams involving hundreds or thousands of students. The platform
will also be adaptable to different academic programs, allowing for customization in exam
formats and content. It will support future expansions, such as integration with other academic
systems or the addition of new features.

1.7.2 Limitations

While the Web-based Exam Management System (WEMS) for Mekdela Amba University
(MAU) provides significant benefits, there are some limitations to its scope and functionality:

 Restricted to MAU Students: The system is designed exclusively for students enrolled at
Mekdela Amba University. It will not support students from other universities or educational
institutions.
 Accessibility Limitations for Visually Impaired Students: The current version of the system
may not be fully accessible to blind or visually impaired students. Further adaptations, such as
screen reader compatibility, may be required in future versions to ensure inclusivity.
 Limited to Regular Students: The system is intended only for regular students of MAU. It does
not cater to weekend students, distance learning students, or other non-regular student groups.
This limitation restricts the system's usage to a specific subset of the university’s student body.

10
 Limited Question Types: The system currently supports automated grading for multiple choice,
true/false, and matching question types.
 Essay-type exams are not supported in the initial version of the system. The automated grading
functionality does not extend to subjective assessments at this stage.

1.8 Significance and Beneficiaries

The Web-based Exam Management System (WEMS) for MAU offers several advantages for
students, teachers, and the educational institution as a whole. These benefits aim to improve the
exam process, enhance efficiency, and foster a more secure, accessible, and flexible learning
environment. Some of the key benefits include:

 Improved Efficiency: The system streamlines the entire exam management process—from
creation and scheduling to grading and result generation.
 Increased Accessibility: The web-based nature of the system allows students to access exams
from any location, at any time, provided they have an internet connection.
 Enhanced Security: The system incorporates various security features, such as randomized
question order, time limits, and anti-cheating measures (e.g., monitoring tools, browser
lockdowns), which help ensure the integrity of exams.
 Improved Data Management: By centralizing all exam data, the system makes it easier to track
and analyze student performance over time.
 Cost Savings: The shift from paper-based exams to an online system reduces costs associated
with printing, distributing, and storing physical exam materials.
 Flexibility for Customization: WEMS provides greater flexibility for both teachers and
students. Teachers can customize exam content, time limits, and question types based on the
specific needs of their courses.

11
1.9 Time and budget

Time Schedule

Table 1. 2 Time Schedule

12-Feb 3-Apr 23-May 12-Jul 31-Aug 20-Oct

requirement gathering and system design 21-Mar 15

DataBase design and setup 1-Apr 30

UI design 1-May 60

Backend development 1-Jul 90

1.10. Organization of the Project

CHAPTER TWO:

SYSTEM REQUIREMENT AND SPECIFICATION (SRS)

System Requirements and Specification (SRS) is a crucial step in the software development
process. The entire system's expected functionality, requirements, and constraints are laid out in

12
this document. The purpose of this chapter is to provide a thorough and precise explanation of
the existing system, the proposed system in question, and the project's overall viability.

2.1 Existing System

2.1.1 Overview

The management of exams in many schools is largely dependent on manual processes and paper-
based records, which are associated with high errors and transparency issues. Currently, the
exam schedule, question paper design, attendance tracking system (PDM), evaluation, and result
compilation are manually managed, making the process time-consuming and subject to human
error. Delays, inaccuracies and security risks are common issues with this system.

Description of Existing Activities

1. Hand-Writing Exam Question Papers: These papers are created by instructors using word
processors and then printed out. It's labor-intensive work that has no basis in law.
2. Attendance records are manually recorded by invigilators during exams, and sheets are
signed by students to prevent any misprint or tampering.
3. The maintenance of academic integrity in physical classrooms is ensured through Exam
Invigilation, which involves teachers or designated monitoring the exam process.
4. Answer Sheets are gathered, shipped, and dispatched for manual evaluation, leading to
time complexity and errors.
5. Manual Result Compilation: The process of manually entering the results into
spreadsheets and publishing them on notice boards often leads to errors. It is a slow,
unreliable and non-syncfunctional traditional system that does not provide any flexibility
required in today's educational context.

13
2.1.2 Functionalities of the Existing System

Users of the Existing System

1. These administrators are accountable for the complete organization of the exam process.
They oversee the arrangement of exams, assign invigilator duties, and allocate seats for
students. Reporting is also a crucial activity that they excel in.'
2. The instructors create exam questions, oversee the session and classroom sessions for
students, grade answer scripts, and submit final grades to each student.
3. The Department Head serves as an academic oversee, ensuring that exams in their
department are consistent with the institution's policies and maintain high academic
standards. Give approval to the timing of final exams, track their completion and tracking
process as well as departmental performance reports and exam results.
4. The exam should be subject to review by the Exam committees and approval by their
instructors. The Exam committees ought to be empowered to choose the institute/college,
department, and course.
5. Student Examinations are held at a predetermined location, with students taking them
physically.

Essential Activities within Current System.

1. Manual Question Papers: Faculty members write question papers, often in Word
documents or other similar formats and submit them for printing.
2. Course Organization: Exams are scheduled while students are in the
classroom/Publication. Students are monitored by invigilators to monitor the
exam environment and ensure compliance with regulations.
3. Manually Assessed Answer Sheets: These sheets are assessed by instructors.
4. Compilation of results involves entering scores into spreadsheets and verifying
final grades before publishing them on notice boards or handing out printed
reports.

Existing System Workflow Structure.

14
1. Manual question preparation is carried out by instructors.
2. Exam Time: Pre-ordered exams are conducted and students receive
notifications.
3. Printing and distributing physical sample question papers to exam venues
is necessary.
4. The exam is conducted in a classroom, and the process is monitored by
invigilators.
5. Teacher assessment: Teachers assess answer sheets.
6. Publishing Results: The compilation and entry of scores involves entering
them into a spreadsheet, which is then made public.

Forms and other documents of the existing systems


Table 2. 1 Instructor Record Scores of Students

Mekdela Amba University


Course Title:_____________ Department: _________
Course No: ______________ Target Group:______
Class Year:_______________ Semester: _______
Marks
No ID No Name Sex
40% 60% 100%
1
2

Table 2. 2 Attendance of the Students

Mekdela Amba University


Department: ________ Group: _________
Course Title:________ Class Year: _________
Course Code:________ Semester: ___________

15
No ID No Sign No ID No Sign
1 4
2 5
3 6
Sign of Instructor: ________
Sign of Invigilator: ________

2.1.3 Business rule

Statements of business policy or procedure are referred to as business rules and they reflect these
[Link]. A company's policies are designed to meet its business objectives, allocate resources
effectively, and adhere to legal or broader business changes. The implementation of business
rules in software can serve as a means of satisfying the requirements of this software system.
Identifying the business rule of this proposed system will enable us to effectively describe each
use case.

Table 2. 3 Business Rules

ID Business rules Description Source


BR-01 All students must register for an exam before the specified Institutional Examination
deadline; late registration is not allowed. Policy
BR-02 A student is not allowed to take two exams scheduled at Academic Regulation
the same time. Handbook
BR-03 Exam results must be submitted to the academic office Internal Administrative Policy
within two weeks of the exam date.
BR-04 A student scoring below 50% in any exam is deemed to Official Grading Policy
have failed and must retake the exam.
BR-05 Any cheating on the exam leads the mark of student to zero Disciplinary Action Policy
or F grade.

16
2.1.4 Drawbacks of the Existing System

The use of the current system for managing exams, which is primarily manual and paper-based,
has several drawbacks that affect its effectiveness and reliability. Along with reducing the
efficiency of exam administration, these shortcomings also pose challenges to data security,
accuracy, and accessibility.

Table 2. 4 Draw back of existing System

No Drawback Description/Impart
1 Inefficiency High time consumption and labor effort in handling exam
preparation and grading
2 Delayed Results Long processing times for grading, affecting timely feedback to
students
3 Inaccuracy Increased human errors in data entry and grading
4 Security Risks Risk of question paper leakage and answer sheet tampering
5 Inaccessibility Exams are limited to on-campus students; remote or differently
abled students excluded
6 Data loss Risk of losing physical documents due to mishandling or
disasters
7 Repetitive work Redundant data entry processes, increasing workload and error
frequency

17
2.2 Proposed System

2.2.1 overview

Mekdela Amba University has developed a web-based exam management system (WBEMS) that
will simplify and automate the entire examination lifecycle. It eliminates the inefficiency of
traditional paper-based exam processes and replaces them with a strong, secure, and adaptable
online platform. The use of WBEMS enables institutions to manage exams in an efficient
manner, while also ensuring accessibility, data security and administrative efficiency. It is also a
web-based system that can be accessed by students and faculty members.

Core features of the Proposed System.

 The platform is web-based and can be accessed on PCs, laptops or other devices to learn
and transform digitally through remote access.
 To prevent unauthorized access, all users (Admin, Instructor, Students, Department
Head, ExamCommittee) are required to use secure credentials. This is done through
authentication methods.
 The system's modular design includes modules such as Exam Setup, Question Bank,
Student Interface, and Result Management to make it easier to manage and scale.
 Automation streamlines the process of scheduling exams, grading objective questions,
and
 producing results, which significantly reduces administrative burden. Students receive
feedback promptly after submission as results are processed and presented.

Key Features of WBEMS

 . Centralized Question Bank. All exam questions are stored in a secure, one-stop shop
called the question bank. Teachers can use it to design, adjust, group, and process a
variety of questions, such as multiple-choice, true/false, matching, among others, in an
orderly and efficient way.

18
 Automated Grading System. An automatic grading module that can assess objective-
type exam questions on the basis of predetermined answer keys is a powerful addition to
the system. The need for manual verification is eliminated as it calculates correct scores
immediately after submission. The reduction of human error is achieved through the
enhancement of grading consistency and fairness.
 Real-Time Result Generation. By generating results in real-time, students can receive
immediate feedback on their performance after completing an exam. After submitting the
exam, the system processes the answers and calculates the scores, resulting in immediate
results.
 Role-Based Access Control (RBAC): Role-Based Access Control (RBAC) is a security
framework that ensures users interact with the system strictly according to their assigned
roles and responsibilities.

Table 2. 5 Role-Based Access Control

Role Responsibilities
Admin User management, system configuration, manage department
Instructor Create/manage exams, grade students
Exam Committee Review and approve exams
Department Head Manage exam Time Table
Student take exams, view results

2.2.2 Functional Requirements

Functional requirements dictate the core behaviors and capabilities that the Web-Based Exam
Management System (WBEMS) must support. These requirements form the basis of user
interaction and system response to inputs, as well as processing of data.[A]. This system is
designed to be fast, flexible, error-free, cost-efficient, and time-saving for users. The system's
computerized examination system satisfies the functional requirements specified by each actor.

19
🔹 Admin. The Admin is the system administrator, responsible for user accounts, role
assignments, and platform configuration. Full access privileges enable the Admin to manage the
system's security, establish institutional exam schedules, and ensure optimal functioning by
managing user access and system-wide settings.

🔹 Instructor. Teachers are the academic backbone of the system. It empowers them to develop
and manage question banks, plan for course-specific exams, and assess student achievement.
Moreover They are responsible for ensuring that content is of high quality and that examinations
meet learning objectives and academic standards.

🔹 Exam Committee. The Exam Committee is the system's quality assurance unit. Their
responsibility is to ensure that exam content meets institutional policies in terms of fairness,
relevance, and conformity. Their aptitude for identifying and filtering exams by department or
course facilitates strategic oversight and the monitoring of academic integrity.

🔹 Department Head. Department Heads are responsible for leading academic activities within
their departments. Their responsibilities include managing instructor-course assignments and
overseeing departmental exam reports, which ensures accountability and alignment with
curriculum objectives. They serve as a bridge between institutional requirements and
departmental operations.

🔹 Student. It is also the main source of income for students, who use it to get into & take part in
regularly scheduled exams. Their access to an exclusive dashboard allows them time to take
exams, receive feedback on their progress, and complete assessments as needed. Their
interaction reflects the system's fundamental goal of conducting exams in an efficient,
transparent manner and with student focus.

Table 2. 6 Functional Requirement

No. Requirement User Roles Key Activities


1 User Registration Admin, Instructor, Exam Enable secure access and
and Login Committee, Department authentication, provide personalized
Head, Student role-based dashboards
2 Exam Admin, Instructor, Exam Create, schedule, assign, approve, and

20
Management Committee, Department control exams based on institutional
Head hierarchy
3 Question Bank Instructor Add, edit, delete questions;;
Management import/export question banks
4 Exam Student, Instructor Students take exams online;
Participation and Instructors perform auto grading
Grading
5 Result Reporting Admin, Instructor, Exam View individual and aggregate results;
and Analytics Committee, Department analyze performance; generate exam
Head, Student and academic reports

2.2.3 Non-Functional Requirements

Non-functional requirements describe user visible aspect of the system that are not directly
related with the function or theirs quality assurance. Non-functional requirement include quality,
respond time, perform and security.
The system should be loyal for different user by the evidence.
I. Performance:
 The system is very fast since it is automated.
 The software shall support use of multiple users at a time.
 It works very well with short response time, high throughput and high availability.
II. Security:
 The system must have error handling.
 The system should display error message if the user input invalid information.
III. Response time:
 The system will let the all users (Administrator, Student, and Instructor) to access the
needed information more quickly. That means the response time of the system is very
fast.

21
IV. Accessibility:
 The system provides access right control for each of its user and every user can
access the data which belong to them.
V. Maintainability
 Backups for database and other sensitive information are available for recovery if
damage is happen.
VI. Availability
 The server should be always on to be available.
 There is no delay in the availability of any information, whatever needed, can be
captured very quickly and easily.
VII. Error handling
 The system must have error handling.
 The system should display error message if the user input invalid information.
VIII. Accuracy
 The Online Examination System provides the uses a quick response with very accurate
information regarding the users etc. Any details or system in an accurate manner, as and
when required.

Table 2. 7 Non-Functional Requirement

No Requirement Description
1 performance <=2 sec response time, supports 100+ concurrent uesrs
2 Scalability Easily accommodates growth in users, departments and
features
3 Security SSL encryption, RBAC, secure login, Protection against
cyber threats
4 Reliability 99.9% uptime with minimal service interruption during
exam periods
5 Backup and Recovery Daily backups and recovery plan to ensure data safety and
quick restoration

22
2.3 Feasibility Study

The system development life cycle relies heavily on the feasibility study. The evaluation
measures the feasibility, practicality, and sustainability of implementing the Web-Based Exam
Management System (WBEMS) at Mekdela Amba University. It is hoped that the project will be
not just technically feasible, but also financially workable and functional within the university's
context.

2.3.1. Operational Feasibility.

Functional capability tests the effectiveness of the proposed system in implementing the
university's existing workflow, culture and resources. Detailed Analysis: Currently, the manual
exam process includes various departments and multiple tasks such as question preparation,
printing/distributing materials to candidates, grading them in advance of their results, etc. These
are time-consuming, laborious, and prone to errors. These operations are made automated by the
proposed system, which introduces a centralized platform that manages all aspects, including
question creation and result generation. Users can expect minimal training requirements from the
system as it provides an intuitive user interface for students, instructors, and administrators. By
utilizing roles, dashboards can streamline user work, increase precision, and improve the overall
user experience. By enabling remote Access, users can conduct exams or participate in tests from
any location, which enhances accessibility and convenience.

2.3.2. Technical Feasibility:

The technical feasibility of the project depends on the use of technology, infrastructure and
human expertise. Technology Stack: Frontend: [Link] is a web framework that is both mature
and flexible, making it suitable for enterprise-level applications. A powerful relational database
system called SQL Server is designed to manage massive quantities of exam-related data
securely and efficiently on the backend. The development of Visual Studio, SQL Server
Management Studio and HTML/CSS/JavaScript is supported by open-source or licensed
resources such as Adobe AIR. Human Resourse Rwadiness. A proficient team in [Link],
SQL and web technologies. The IT support team at Mekdela Amba University has expertise in

23
web systems and databases.; Long-term maintainability will be guaranteed by the comprehensive
documentation and modular code.

2.3.3. Economic Feasibility:

The cost effectiveness of the system is evaluated through economic feasibility, which measures
its potential benefits over expenses related to design and operation. Cost Analysis.

Initial development cost:

 System Design and Development.


 Database and Server Setup.
 UI/UX and Testing.
 User documentation and training sessions.

Maintenance and Support:

 Regular system updates.


 Bug fixes and enhancements.
 Data backups and storage.

Table 2. 8 Feasibility Area/ Study

No Feasibility Area Evaluation Summary


1 Operational Greatly improves exam efficiency, minimizes manual work, and
enhances user experience
2 Technical Uses proven technologies, easly to maintain, supports future
scalability
3 Economic Uses proven technologies, easly to maintain, supports future
scalability

24
CHAPTER THREE: SYSTEM MODELING
System modeling is the process of developing abstract representations of a system to understand
and analyze its structure and behavior before the system is built. These models help software
engineers, system designers, and stakeholders visualize the system, identify potential design
flaws early, and guide the development process efficiently. For the Web-Based Exam
Management System (WEMS), modeling serves as a blueprint for building a robust, user-
friendly, and efficient exam management platform.

3.1 Use Case Model

Identifying Actors

In system modeling, actors represent all external entities that interact with the system. These may
be human users or other systems, and they either initiate actions or respond to system activities.
Identifying the right actors is essential for defining system functionality, ensuring role-based
access, and clarifying use case boundaries.

1. Admin

The Admin is the core system overseer responsible for ensuring the platform's smooth operation
and security. This role includes managing user accounts across all other roles (instructors,
students, exam committee, department heads), configuring institutional data such as colleges,
departments, and courses, and setting up exam schedules. The admin also holds the authority to
review and manually grade subjective answers when required, ensuring flexibility beyond
automated assessments. This role plays a crucial part in system governance, policy enforcement,
and overall maintenance.

2. Instructor

Instructors are academic users tasked with content creation and exam execution. Their
responsibilities include managing course-specific question banks, uploading teaching and exam
preparation materials, and assembling exam sets. They can log in based on their associated
college, department, and course, allowing tailored access to relevant academic data. Post-exam,

25
instructors can view and analyze students’ performances, manually grade subjective answers,
and provide academic feedback. Their involvement ensures educational quality and exam
integrity.

3. Student

Students are the primary end-users of WEMS, responsible for taking exams and accessing
educational content. Each student logs in using a secure personal account to participate in
scheduled assessments, submit answers, download study resources, and view individual results.
The student portal is designed to be user-friendly and secure, providing students with access to
their academic profile, upcoming exams, and real-time feedback, promoting self-assessment and
progress tracking.

4. Exam Committee

The Exam Committee is a dedicated quality assurance body within WEMS that reviews and
validates all exams before publication. Committee members are authorized to log in, select
relevant colleges, departments, and courses, and evaluate the completeness, fairness, and
compliance of exams created by instructors. Once an exam is approved, it becomes available for
scheduling. Their role ensures that assessments meet institutional standards, are free from bias,
and align with academic regulations.

5. Department Head

The Department Head acts as the academic manager for a specific department. This role includes
monitoring the department’s courses, instructors, and exams, while ensuring alignment with
institutional academic policies. Department Heads can view departmental reports, oversee exam
and result trends, and support resource planning. Their strategic oversight contributes to
improving teaching quality, exam standards, and overall departmental performance.

Use Case

Table 3. 1 Use case and there Description

No Use Case Description Actor(s)

26
1 Login Securely authenticate users via All Users
username and password.
2 Manage Users Create, update, or remove user Administrator
accounts and assign roles.
3 Manage Departments Add, edit, and delete academic Administrator
departments.
4 Manage Courses Manage course information and assign Administrator,
instructors.
5 Manage Institutes Handle institutional data if multiple Administrator
campuses are involved.
6 Manage Exam Schedule Define or update exam schedules Administrator,
across the system. Instructor
7 Manage Questions Create, edit, and remove questions of Instructor
different types.
8 Create Exam Compile questions into formal exams Instructor
and configure exam rules.
9 Schedule Exam Set exam date and time for students. Instructor
10 Review Exam Preview and verify exams before Instructor,
submission. Administrator
11 Approve Exam Official approval of exams after Department Head
review.
12 Take Exam Students attend and submit scheduled Student
exams.
13 View Own Result Students review their individual scores Student
and performance.
14 View Own Profile / Users can view and manage their All Users
Change Password profiles and passwords.
15 View Course Access course-related information and Student, Instructor
associated resources.
16 Register for Exam Sign up for an upcoming exam. Student
17 Check Exam Schedule Preview upcoming exams, dates, and Student

27
requirements.
18 Manage Exam Timetable Create and update a structured Department Head
timetable for exams.
19 Monitor Department- Track and monitor exam activities Department Head
Wide Exams within the department.
20 Approve Exam Grant final approval for exams to Department Head
(Department Level) proceed.
21 Check Exam Validate exam settings and integrity Exam Committee
before it is administered.
22 View Committee Profile View and update exam committee Exam Committee
member information.

Use Case Diagram

The use case diagram visually represents system interactions from the perspective of each actor.
Use relationships like:

 <<include>>: Common functionality reused in other use cases (e.g., "Verify Identity"
included in both "Login" and "Reset Password").
 <<extend>>: Optional behaviors (e.g., "Approve exam" extends "Check exam").

28
Figure 3. 1 Use Case of the System

3.1.1 System use case documentation

Table 3. 2 System Use Case Documentation

Use Case ID Use Case Name Include

UC1 Login ….

UC2 Manage user Login

UC3 Manage course Login

29
UC4 Manage department Login

UC5 Manage question Login

UC6 Manage Exam Schedule Login

UC7 View Result Login

UC8 View profile Login

UC9 View Course Login

UC10 Take exam Login

UC11 Check exam Login

UC12 Register for exam Login

UC14 Manage exam timetable and Login


Schedule

UC15 Approve exam question Login

UC16 Monitoring department wide Login


exam

UC17 Logout Login

3.1.2 Use case Description

Table 3. 3 Use Case Description for Manage User

UCID- UC Name Manage users


02 UC Description Enables System Admin to Manage Users (create,
change, delete) of the Users of the System.
Actor Administrator
Precondition The users (instructors, students, Exam Committee) must
be the member of the University.
Flow of event [Link] administrator clicks Manage users button on the

30
Admin page.
[Link] system displays the roll down menu option of the
Users(students, instructor, and exam committee).
[Link] administrator chooses menu and perform the
action (create, change, delete) to be performed.
[Link] system displays the data entry page for respective
action of selected menu.
[Link] administrator enters the required information of
users of the system
[Link] system save account of the Users.
Post condition The account of the users altered (created, or changed or
deleted)
Alternative course A1: Wrong data Entry Message
of action
[Link] system displays “Wrong data Entry!”
message.
[Link] system resumes at step 4.
A2: Missing of Required Information Message

[Link] system displays “Enter all information!”


massage.
[Link] system resumes at step 4.
B2: Invalid Action Message

[Link] system displays “Invalid Action!” massage.


[Link] system resumes at step 4.

Table 3. 4 Use Case Description for Manage Department

UCID- UC Name Manage Department


UC Description Enables System Admin to manage departments of each

31
institutes or colleges in the University.
Actor Administrator
Precondition The department must be registered to respective
institutes.
Flow of event [Link] administrator clicks Manage Department button
on the Admin page.
[Link] system displays the Manage Department page.
[Link] administrator selects actions (adding, changing
and deleting departments) to be performed on
departments.
[Link] system displays data entry page.
[Link] administrator enters the information of

04 departments of the institute or college.


[Link] system the actions performed on departments.
Post condition The department every institute or college of the system
is managed.
Alternative course A1: Wrong data Entry Message
of action
1. The system displays “Wrong data Entry!”
message.
2. The system resumes at step 4.
A2: Invalid action Message

[Link] system displays “Invalid Action!” massage.


The system resumes at step 4.

Table 3. 5 Use Case Description for Manage Examination

UCID- UC Name Manage Examination

32
05 UC Description Enables instructors to add the questions with respective
answer to the system.
Actor Instructor, administrator
Precondition Exam must be prepared
Flow of event [Link] instructor clicks Manage Examination button
from Instructor page.
[Link] system displays the department and course
chooses form for instructor.
[Link] instructor chooses the department and course.
[Link] system displays the add Question page.
[Link] instructor adds questions with respective
answers and allowed time for the exam to the system
with.
[Link] system finishes adding question.
[Link] question has subjective part the admin checks
manually and result is added to that of objective part
Post condition Examination is added onto the system with answer and
allowed time.
Alternative course B1: Choose Message
of action
[Link] system displays, “Please choose department and
course” message.
[Link] system resumes at step 2.
B2: Invalid Choice Message

[Link] system displays, “You are not teaching this


course or You are not instructor of this department”
message.
[Link] system resumes at step 2.
B3: Add time Message

[Link] system displays, “Please Add Allowed Time for

33
exam!” message.
[Link] system resumes at step 4.

Table 3. 6 Use Case Description for View Student Result

UCID- UC Name View Student Result

07 UC Description Enables student to see their own results after they


finished the exam and instructors to see results of all
students.
Actor Instructor, Student
Precondition The examination process must be taken place
Flow of event [Link] student or instructor or clicks View Student
Result button from home page.
[Link] system displays the department, year and course
choose page for student.
[Link] student and instructor choose department, year
and course that he wants to see result.
[Link] system displays the result page for student and
instructor.
[Link] student sees his/her own result for that exam.
[Link] system closes the result page.
Post condition The result is displayed to the respective user
Alternative B1: Invalid Choice Message
course of action
1. The system displays, “Incorrect Department
choose, please enter the correct one!” message.
2. The system resumes at step 2.
B2: Invalid Choice Message

[Link] system displays, “You are not taking this

34
course, please!” message.
[Link] system resumes at step 2.
B3: Exam not Taken Message

1. The system displays,” Exam is no taken you


can’t see result” message.
2. The system resumes at step 2.

Table 3. 7 Use Case Description for Take Exam

UCID- UC Name Take Exam

10 UC Description Enables student to do examination.


Actor Student
Precondition Student must be registered for that course and attend the class
Flow of event [Link] student clicks Read Exam button from home page.
[Link] system displays the department, year and course
choose page for student.
[Link] student chooses the department, year and course that
he wants to read examination.
[Link] system displays the examination page.
5. The student reads the exam questions and selects choose
which he/she realized to be correct answer and clicks
Submit Answer button.
6. The system closes the examination page and displays the
result of the student.
Post condition The student already taken exam.
Alternative B1: Invalid Choice Message
course of action
[Link] system displays, “Incorrect Department choose,
please enter the correct one!” message.

35
[Link] system resumes at step 2.
B2: Choose Message

[Link] system displays,” Please choose course you


want to do exam for” message.
[Link] system resumes at step 2.
B3: Invalid Choice Message

1. The system displays, “You are not taking this


course, please!” message.
[Link] system resumes at step 2.
B4: Time is up Message

[Link] system displays, “The time allowed for this


exam is over!” message.
[Link] system resumes at step 6.

Table 3. 8 Use Case Description for Check Exam

UCID- UC Name Check Exam

11 UC Description Enables Exam Committee to check the exam prepared


by instructors.
Actor Exam Committee
Precondition The exam must be added to the system by instructor
Flow of event [Link] Exam Committee clicks Check Exam button on
the Exam Committee page.
[Link] system displays the department and course
chooses form for Exam Committee.
[Link] Exam Committee selects the Department, and
course he/she want to check questions for.
[Link] Exam Committee reads the question and approve
it.

36
[Link] system sends the exam to student page.
Post condition The account of the user is deleted; the user can not enter
to the system or denied to access.
Alternative course A1: Wrong data Entry Message
of action
1. The system displays “Wrong data Entry!”
message.
2. The system resumes at step 2.
A2: Invalid action Message

1. The system displays “Question is not Added!”


massage.
[Link] system resumes at step 2.

3.2 Conceptual Modeling(Analysis Level Class Diagram).

Class is nothing but a structure that contains both variables and methods. The Class Diagram
shows a set of classes, interfaces, and collaborations and their relating ships. It shows the
dependency between the classes that can be used in our system. The interactions between the
modules or classes of our projects are shown below. Each block contains Class Name, Variables
and Methods.

37
Figure 3. 2 Class Diagram for WBEMS

3.3 Key Abstraction with CRC Analysis

CRC (Class-Responsibility-Collaboration) cards are used to define the system’s objects by


specifying:

38
Figure 3. 3 CRC Cards for WBEMS

3.4 Object Diagram

39
Figure 3. 4 Object Diagram for WBEMS

3.5 Dynamic Model

Dynamic models illustrate how system elements interact and change over time in response to
events and processes.

3.5.1 Sequence diagram

Sequence diagrams show a succession of interactions between classes or object instances over
time. The Sequence diagrams of some classes are given bellow.

40
Figure 3. 5 Sequence Diagram for Login

41
Figure 3. 6 Sequence Diagram for Manage User

42
Figure 3. 7 Sequence Diagram for Manage Department

43
Figure 3. 8 Sequence Diagram for Take Exam

44
Figure 3. 9 Sequence Diagram for View Result

3.5.2 Activity Diagram

Activity diagram is another important diagram in UML to describe the dynamic aspects of the
system. It is basically a flowchart to represent the flow from one activity to another activity. The
activity can be described as an operation of the system. The control flow is drawn from one
operation to another. This flow can be sequential, branched, or concurrent.

45
Figure 3. 10 Activity Diagram for Login

46
Figure 3. 11 Sequence Diagram for Admin

47
Figure 3. 12 Sequence Diagram for Instructor

48
Figure 3. 13 Sequence Diagram for Student

3.5.3 State Chart Diagram

State chart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered. The

49
most important purpose of State chart diagram is to model lifetime of an object from creation to
termination.

Figure 3. 14 State Chart Diagram for Login

50
Figure 3. 15 State Chart Diagram for Take Exam

51
Figure 3. 16 State Chart Diagram for Manage Exam Schedule

52
Figure 3. 17 State Chart Diagram for Check Exam

53
3.5.4 User Interface Prototype

Figure 3. 18 User Interface Prototype for WBEMS

CHAPTER FOUR: SYSTEM DESIGN


4.1. Introduction

System design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements. It serves as a blueprint for building the
software system. Design involves applying patterns observed during the analysis phase to the
design phase, refining and adapting them for implementation. System design defines the
elements of a system, including its architecture, modules, components, interfaces, and data flow,

54
to meet the specific needs and requirements of a business or organization and ensure a coherent
and well-functioning system.

4.1.1. Overview of System Design Goal

Software design is the process of translating the requirements gathered during the analysis phase
into a representation of the software. It includes conceiving, planning, and specifying the
externally observable characteristics of the software product, as well as its internal structure. The
goal of the design process is to provide a detailed blueprint that guides the implementation,
testing, and maintenance activities.

For the Web-based Exam Management System (WEMS) at Mekdela Amba University, the
platform is designed to address the challenges and limitations of the existing manual exam
management system. These challenges include:

 Inefficiency: Time-consuming processes for exam creation, scheduling, grading, and


result dissemination.
 Errors: Potential for manual errors in grading, record-keeping, and schedule
management.
 Limited Accessibility: Difficulty for remote students or instructors to participate in or
manage exams.
 Lack of Security: Vulnerabilities associated with paper-based exams and manual record-
keeping.
 Scalability Issues: Difficulty in handling a growing number of students and exams.

The project design goals for WEMS are:

 Streamlined Exam Administration: To automate and simplify the processes of exam


creation, scheduling, delivery, and grading.
 Enhanced Security and Integrity: To provide a secure platform that protects the
integrity of exams and student data.
 Improved Accessibility and Flexibility: To enable students and instructors to interact
with the exam system from anywhere with an internet connection.

55
 Data-Driven Insights: To provide tools for generating reports and analytics on student
performance and exam effectiveness.
 Scalability and Maintainability: To design a system that can accommodate future
growth and is easy to maintain and update.

The project aims to achieve the following key goals:

 Efficient Exam Management: Reducing the administrative overhead associated with


traditional exam processes.
 Secure and Reliable Platform: Ensuring the confidentiality, integrity, and availability of
exam-related data.
 User-Friendly Experience: Providing intuitive interfaces for all user roles
(Administrator, Instructor, Student, Exam Committee).
 Scalability and Maintainability: Designing a system that can accommodate future
growth and is easy to maintain and update.
 Improved Learning Outcomes: Facilitating effective assessment and feedback to
enhance the learning process.

4.1.2. Design Goals

Design goals are desirable qualities derived from non-functional requirements that guide the
design process. For the Web-based Exam Management System, the key design goals,
characterized by different criteria, are:

 End-User Criteria:
o Usability: The system should be easy to learn and use for all actors, with clear
navigation and intuitive interfaces.
o Accessibility: The system should be accessible to users with disabilities, adhering
to relevant accessibility standards.
o Responsiveness: The system should provide quick and timely responses to user
actions, ensuring a smooth and efficient experience.

56
o User Satisfaction: The overall experience of using the system should be positive,
efficient, and contribute to user productivity.
 Maintenance Criteria:
o Maintainability: The system should be designed in a modular and well-
documented manner to facilitate easy modification, bug fixing, and updates.
o Scalability: The system architecture should allow for future expansion to
accommodate increasing user loads, data volumes, and new features without
significant redesign.
o Extensibility: The system should be designed to allow the addition of new
features and functionalities with minimal impact on existing components.
o Testability: The system should be designed to facilitate testing at various levels
(unit, integration, system) to ensure quality and reliability.
 Performance Criteria:
o Efficiency: The system should utilize resources (CPU, memory, network)
effectively to ensure optimal performance.
o Throughput: The system should be able to handle a large number of concurrent
users and transactions without significant degradation in performance.
o Response Time: Critical operations, such as exam submission, result viewing,
and question loading, should have minimal response times.
 Cost Criteria:
o Development Cost: The design should aim for efficient development practices,
appropriate technology choices, and minimize development effort to control costs.
o Operational Cost: The system should be designed to minimize ongoing
operational costs, including hosting, maintenance, support, and infrastructure.
 Dependability Criteria:
o Reliability: The system should operate without failure under specified conditions
for a specified period, ensuring consistent and dependable service.
o Security: The system should protect sensitive data (user credentials, exam
content, results) from unauthorized access, modification, or disclosure, adhering
to security best practices.

57
o Availability: The system should be accessible to authorized users when needed,
with minimal downtime, ensuring continuous operation.
o Fault Tolerance: The system should be able to continue operating correctly in
the presence of hardware or software faults, ensuring resilience.

4.2. Detailed Class Model

The Design Class Model provides a detailed view of the classes identified during analysis,
including attribute data types, method signatures (name, parameters with data types, return
types), access visibility, multiplicity of relationships, and role names.

58
Figure 4. 0-1 Class model for WBEMS

4.3. Current Software Architecture

The existing system at Mekdela Amba University for managing examinations is primarily a
manual system involving paper-based exams, manual grading, and physical record-keeping.
Therefore, there is no current software architecture to consider. The following sections will
describe the proposed software architecture for the new Web-based Exam Management System.

59
4.4. Sub-System Decomposition with Services

To manage the complexity of the Web-based Exam Management System, we can decompose it
into the following logical subsystems, each providing a set of related services:

Subsystem Descriptions:

 User Management Service: Provides services for user registration, login, profile
management, and role-based access control.
 Exam Management Service: Offers functionalities for instructors to create, manage, and
schedule exams, and for managing the question bank.
 Exam Delivery Service: is handles/responsible for presenting exams to students,
including the exam-taking interface, answer submission, and potentially real-time
monitoring.
 Grading and Result Service: Provides services for automated and manual grading of
exams, calculation of results, and generation of result reports.
 Administration and Security Service: Manages system-level configurations, audit
logging, access control, and data backup and recovery.

60
Figure 4. 0-2 Sub-System Decomposition Diagram for WBEMS

4.5. Proposed System Architecture

The proposed Web-Based Exam Management System (WBEMS) is designed using a Three-
Tier Architecture. This architecture divides the system into three separate layers, each
responsible for a distinct function. This helps make the system easier to manage, expand, and
secure.

1. Presentation Tier

The presentation tier is the top layer of the system that users interact with directly. It displays
information to users and collects input from them through a graphical user interface (GUI).

2. Application Tier

The application tier is the middle layer that handles the processing of data and the execution of
business logic. It acts as a bridge between the user interface and the database, making decisions
and managing the flow of data.

61
3. Data Tier

The data tier is the bottom layer where all system data is stored and managed. It is responsible
for organizing, retrieving, and saving data in a structured way to support the functioning of the
system.

Figure 4. 0-3 System Architecture Diagram for WBEMS

4.6. Component Diagram

The Component Diagram illustrates the high-level software components of the system, their
dependencies, and communication pathways.

62
Figure 4. 0-4 Component Diagram for WBEMS

4.7. Deployment Diagram (Hardware / Software Mapping)

A deployment diagram is a type of diagram that specifies the physical hardware on which the
software system will execute

A Deployment Diagram describes the physical deployment of software artifacts on hardware


nodes. It provides a visual representation of how the system's components both software and
hardware are distributed across the system's architecture. This diagram focuses on the interaction
between the system's physical architecture and its logical components.

For the Web-Based Exam Management System, the deployment diagram


illustrates:

63
 Client Machines: Web browsers (e.g., Chrome, Firefox) used by students, instructors,
and exam committee members to interact with the system.
 Web Server: Hosts the [Link] application. Responsible for processing requests,
handling business logic, and managing user sessions.
 Database Server: SQL Server that stores persistent data like student records, exam
schedules, results, and user credentials.

Figure 4. 0-5 Deployment Modeling for WBEMS

4.8. Persistence Model

64
The Persistence Model outlines how data objects within the system are stored persistently using
a database. In WBEMS, Microsoft SQL Server is used to manage the storage and retrieval of
data. The persistence model ensures that critical information remains available across sessions
and system failures.

Figure 4. 0-6 Persistence Modeling for WBEMS

4.9. Access Control and Security

Access control ensures that only authorized users can perform specific operations within the
system. It forms the backbone of the WBEMS's security architecture, encompassing:

65
 Role-Based Access Control (RBAC): Users are assigned roles (Admin, Instructor,
Student, Exam Committee, Department Head), each with defined permissions.
 Authentication: Verifying user identity via username and password.
 Authorization: Determining user privileges once authenticated.
 Data Protection: Sensitive data (e.g., grades, passwords) is encrypted both in transit
(using HTTPS) and at rest (in the database).
 Physical and Administrative Controls: Server room access restrictions, system logs,
and routine backups contribute to the overall security posture.

Table 4. 1 Use Case or Fuctionality for Actor

Use Case / Admin Instructor Exam Committee Department Student


Functionality Head
Login ✔ ✔ ✔ ✔ ✔
Manage User ✔(Full ❌ ❌ ❌ ❌
)
Manage Course ✔(Full Suggest/Edit View only Approve/View View
) only
Manage ✔(Full ❌ ❌ View only ❌
Department )
Manage Question ❌ ✔(Create/ ✔(Approve/ View only ❌
Edit) View)
Manage Exam ✔(Full Propose Edit/Finalize View only View
Schedule ) only
View Result ❌ ✔(Own class) ❌ ❌ ✔(Own)
View Profile ✔ ✔ ✔ ✔ ✔
View Course ❌ ✔ ❌ ❌ ✔
Take Exam ❌ ❌ ❌ ❌ ✔
Check Exam ❌ ✔(Evaluate) Review/Verify View only ❌
Register for ❌ View only View only View only ✔(Self)
Exam
Manage Exam ✔ Suggest Approve Approve View

66
Timetable & only
Schedule
Approve Exam ❌ Submit only ✔(Approve) ✔(Approve) ❌
Question
Monitor ✔ ❌ ✔ ✔ ❌
Department-wide
Exams

4.10. Global Control Flow

4.10.1. Procedural-Driven Control Flow

In a procedural control flow, the system interaction follows a well-defined sequence of steps.
Each task or process is executed in a predefined order.

Example Registration Process:

User accesses the registration page.


Fills out the required form fields.
Submits the form.
System validates the input.
Upon success, a confirmation message and user credentials are generated.

4.10.2. Event-Driven Control Flow

The event-driven control flow responds dynamically to user actions, such as clicks, searches, or
form inputs, providing a more flexible and responsive experience.

Example – Exam Search:

The user types a keyword (e.g., "Computer Science").


The system filters available exams in real time.

67
Results are displayed dynamically without requiring a page reload.

4.11. Boundary Conditions and Exception Handling

4.11.1. Boundary Conditions

In the context of the Web-Based Exam Management System (WBEMS), boundary conditions
define the points at which users interact with the system and the system interfaces with external
entities or systems, particularly through user interfaces and system entry points. These
boundaries also define preconditions and environmental setups required for effective system
operation, both on the client and server sides.

Table 4. 2 Boundary Type

Boundary Condition Description


Type
Client-Side Stable Internet Users must have a reliable internet connection to
Connection interact with WBEMS via a web browser.
Valid Login Credentials Access to the system requires a username and
password assigned by the administrator.
Correct URL Access Users must enter the correct system URL to reach
the login interface and web application.
Compatible Web Users must use a supported browser (e.g., Chrome,
Browser Firefox, Edge) for optimal performance.
User Interfaces Accessed through structured pages such as Login,
Dashboard, Exam Page, Results, Profile, etc.
Device Compatibility System is accessible from desktops, laptops, tablets,
and smartphones with standard browsers.
Server-Side Admin Privileges Only authorized administrators can configure or
manage server-side settings and resources.
Registered Domain & The server requires a registered domain and
Internet Access uninterrupted internet for remote access.
Web Server A web server (e.g., IIS, Apache) must be installed

68
Environment and properly configured.
Integrated Database A database server (e.g., SQL Server) must be
Server connected to handle application data.
Backup and Recovery Regular automated backups must be configured to
Mechanism recover data in case of system failure.
24/7 Availability The server should remain operational continuously,
except during maintenance periods.
Security Configuration Firewalls, SSL certificates, and role-based access
must be in place to protect system integrity.

4.11.2. Exception Handling

Exception handling in WBEMS ensures that unexpected errors or anomalies during user
interaction or system operation are gracefully managed without system crashes or data loss. The
system implements mechanisms to:

Table 4. 3 Types of Exception

Level Type of Exception Handling Mechanism


Client Side Invalid login credentials Display a clear message like “Incorrect
username or password.”
Expired or unauthorized exam Show an alert indicating that the link is
link invalid or access is denied.
Session timeout or lost Prompt user to retry or inform them of the
connectivity during submission issue with a reconnect option.
Invalid form input Real-time form validation with inline error

69
messages to guide correct input.
Server Side HTTP 500 Internal Server Error Log error details; show a generic error page
to the user without exposing internals.
Database connection failure Automatically log the failure and alert system
administrators for immediate action.
Unauthorized access attempt Log the event, restrict access, and notify the
admin via email or system alert.
Application-level exceptions Use try-catch blocks to handle errors
(e.g., null pointers) gracefully and maintain system stability.
General Logging All exceptions are logged in structured logs
Actions for future debugging and audits.
Admin Notification Critical errors trigger alerts to administrators
via email or system notifications.
User Feedback Display user-friendly error messages to avoid
confusion or frustration.

4.12. User Interface Design

The User Interface (UI) Design of WBEMS follows modern design principles that prioritize
usability, accessibility, and efficiency.

70
Figure 4. 0-7 User Interface for Login

71
Figure 4. 0-8 User Interface for Manage User

72
Figure 4. 0-9 User Interface for Manage course

73
Figure 4. 0-10 User Interface for take exam

74
Figure 4. 0-11 User Interface for view result

75
Figure 4. 0-12 User Interface for Check exam

76
References

[1] S. Bobde, S. Chaudhari, J. Golguri, and R. Shahane, “Web based online examination
system,” Glob. Res Dev. J Eng, vol. 2, no. 5, pp. 58–61, 2017.
[2] Urge Abdullahi Ibrahim Beker Dawid Yusuf Abebech Tafese Gemachu Mohamed
Maraba Wakene Ifa Abera, “Final Project1 | PDF | Test (Assessment) | Standardized
Tests.” Accessed: May 24, 2025. [Online]. Available:
[3] G. B. T. T. Mesfin Adane, “(1) ONLINE EXAMINATION FO Copy.” Accessed: May 24,
2025. [Online]. Available:
[Link]
[4] S. A. F. A. A. A. D. B. Zeydan Abdi, “[Link]
- Online Examination System For Distance Learners Chapter One Requirement Analysis
Documentation 1. | Course Hero.” Accessed: May 24, 2025. [Online]. Available:
[Link]
phpapp01docx/
[5] F. A. M. M. Letu Abera, “Online Examination System | PDF | Software Testing | Use
Case.” Accessed: May 24, 2025. [Online]. Available:
[Link]

77

You might also like