PONDICHERRY UNIVERSITY

(A Central university)

Computer Science Report Template and Report

Writing Guide

FirstName(s) LastName

Supervisor: Supervisor’s Name

A report submitted in partial fulfilment of the requirements of

the University of Reading for the degree of
Master of Science in Data Science and Advanced Computing

April 23, 2025

Declaration

I, Firstname(s) Lastname, of the Department of Computer Science, Uni-

versity of Reading, confirm that this is my own work and figures, tables,
equations, code snippets, artworks, and illustrations in this report are orig-
inal and have not been taken from any other person’s work, except where
the works of others have been explicitly acknowledged, quoted, and refer-
enced. I understand that if failing to do so will be considered a case of
plagiarism. Plagiarism is a form of academic misconduct and will be pe-
nalised accordingly.

I give consent to a copy of my report being shared with future students as

an exemplar.

I give consent for my work to be made available more widely to members

of UoR and public with interest in teaching, learning and research.

Firstname(s) Lastname
April 23, 2025

i
 Abstract

This project introduces an interactive alumni website for the Department

of Computer Science, Pondicherry University, aimed at fostering stronger
connections between alumni, students, and faculty. The platform supports
networking, mentorship, and the sharing of departmental updates, encour-
aging alumni to stay engaged and contribute back to the institution. A key
feature is the Alumni Directory, which helps reconnect former classmates,
and the Student Directory, where current students can showcase their skills
and projects as a digital portfolio. These profiles can also be presented to
recruiters during placement drives or when inviting companies to campus,
enhancing students’ career opportunities. The system additionally tracks
alumni career paths—such as higher studies or employment—for reporting
to accreditation bodies like NAAC. Overall, the platform enhances commu-
nity building and supports institutional growth.

ii
 Acknowledgements

I would like to express my deepest gratitude to my guide, Dr. KRISH-

NAPRIYA for her valuable guidance, consistent encouragement, personal
caring, timely help and providing me with an excellent atmosphere for do-
ing research. All through the work, in spite of her busy schedule, she has
extended cheerful and cordial support to me for completing this project.

iii
Contents

List of Figures vi

List of Tables vii

1 Introduction 1
1.1 About The Project . . . . . . . . . . . . . . . . . . . . . . 1
1.2 About The Organization . . . . . . . . . . . . . . . . . . . 2

2 System Analysis 4
2.1 Requirement Analysis . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Functional Requirements . . . . . . . . . . . . . . . 4
2.1.2 Non-Functional Requirements . . . . . . . . . . . . 5
2.1.3 User Requirements . . . . . . . . . . . . . . . . . . 6
2.1.4 System Requirements . . . . . . . . . . . . . . . . 7
2.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 User Authentication . . . . . . . . . . . . . . . . . 8
2.2.2 Profile Management . . . . . . . . . . . . . . . . . 9
2.2.3 Admin Dashboard . . . . . . . . . . . . . . . . . . 10
2.2.4 Job/Internship Opportunity . . . . . . . . . . . . . 12
2.2.5 Alumni/Student Directory . . . . . . . . . . . . . . 13

3 System Design 15
3.1 UI design . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 UI design . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Architectural design . . . . . . . . . . . . . . . . . . . . . 15
3.3 Database Design . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . 18

iv
CONTENTS v

4 Implementation 19
4.1 Implementation Design . . . . . . . . . . . . . . . . . . . . 19
4.2 Example of a Table in LATEX . . . . . . . . . . . . . . . . . 20

5 Testing 21
5.1 A section . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Conclusions and Future Work 22

6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . 22

7 Codes 24

References 26

Appendices 27

A Codes) 27

B Screenshots 28
List of Figures

2.1 User Authentication Use Case Diagram. . . . . . . . . . . . 9

2.2 Profile Management Use Case Diagram. . . . . . . . . . . . 10
2.3 Admin Dashboard Use Case Diagram. . . . . . . . . . . . . 12
2.4 Job/Internship Opportunity Use Case Diagram. . . . . . . . 13
2.5 Alumni/Student Directory Use Case Diagram. . . . . . . . 14
3.1 Example figure in LATEX. . . . . . . . . . . . . . . . . . . . 17

vi
List of Tables

3.1 Undergraduate report template structure . . . . . . . . . . 16

4.1 Example of a table in LATEX . . . . . . . . . . . . . . . . . 20

vii
List of Abbreviations

SMPCS School of Mathematical, Physical and Computational Sci-

ences

viii
Chapter 1

Introduction

1.1 About The Project

This project focuses on developing an interactive alumni website for the De-
partment of Computer Science, Pondicherry University, to strengthen
the connection between alumni and the department. The platform is de-
signed to facilitate ongoing engagement, foster a sense of community, and
maintain meaningful relationships with former students. Beyond serving as
a hub for networking and communication, the system also collects data on
alumni career paths—specifically, whether graduates pursue higher studies
or enter the workforce. This data is especially important for departmental
reporting to accreditation bodies such as the National Assessment and
Accreditation Council (NAAC). Maintaining an updated alumni database
also allows current students to connect with graduates for mentorship, in-
ternships, and career guidance.

Some of the key modules such as Events, News, Blogs, Payement, Men-
torship, User profile, Admin Dashboard(populated by analytics of the
student/alumni profile data) a dynamic Home page, Gallery and much
more. Each of these components is integrated with a backend API to en-
sure content is current and delivered dynamically. Staying informed about
departmental events, even after leaving campus, can evoke a sense of nos-
talgia among alumni. Access to updates such as research papers published
by faculty, student achievements, and departmental milestones helps alumni
stay connected and may encourage them to contribute back to the insti-
tution that helped shape their careers. The information is organized using
category-based filtering, allowing users to easily navigate the updates and
highlights that interest them.

1
CHAPTER 1. INTRODUCTION 2

A key feature of the platform is the Alumni Directory, which enables

alumni to reconnect and catch up with old classmates, fostering stronger
bonds within the department’s extended community. In addition, the plat-
form introduces a Student Directory, where current students can up-
load their profiles, including skills, projects, and links to GitHub or GitLab
repositories. This acts as a digital portfolio, providing a more interactive
and modern alternative to traditional résumé formats. It can also serve as
a centralized space to showcase student talent to prospective recruiters
and companies during placement drives.

The platform is built using React.js for the frontend and Django REST
Framework for the backend. It emphasizes responsiveness, user experience,
and secure data handling, offering a robust and scalable solution that sup-
ports the department’s outreach goals and long-term alumni and student
engagement.

1.2 About The Organization

The platform is specifically tailored to PUDoCS – Pondicherry Univer-

sity Department of Computer Science, a premier academic department
within Pondicherry University, known for its excellence in teaching, research,
and innovation in the field of computer science. The department offers in-
tegrated and postgraduate programs that combine theoretical depth with
practical skills, helping students build a strong foundation for careers in
academia, industry, and research.

Over the years, the department has produced a diverse group of grad-
uates who have gone on to contribute in various sectors across India and
abroad. While these alumni remain an important part of the department’s
legacy, there has been no dedicated digital platform to maintain regular
communication, facilitate networking, or support collaboration between the
department and its alumni.

This lack of a centralized system has also limited opportunities for current
students to benefit from alumni guidance, mentorship, and career support.
Recognizing this gap, the department initiated the development of a dy-
namic alumni platform aimed at strengthening connections, supporting
student-alumni interaction, and preserving institutional history. This project
CHAPTER 1. INTRODUCTION 3

not only addresses a long-standing need, but also aligns with the depart-
ment’s larger goals of building community, supporting student growth, and
improving institutional outreach.
Chapter 2

System Analysis

System analysis involves studying the current limitations (such as the lack
of a unified platform for alumni engagement) and identifying how a new
system can overcome these through structured planning, design, and inte-
gration of various components. It also helps in modeling how data flows
through the system and how different users interact with it.

The goal is to develop a scalable, secure, and user-friendly platform that

connects alumni, students, and administrators efficiently, while also sup-
porting backend administrative needs and front-end user engagement.

2.1 Requirement Analysis

Requirement analysis is a crucial phase in the software development lifecy-

cle where the needs and expectations of users are gathered, analyzed, and
documented. It helps in understanding what the system should accomplish
and lays the foundation for designing, developing, and testing the applica-
tion.

In this project, requirement analysis defines the scope of the alumni platform
for the Department of Computer Science, Pondicherry University. It ensures
that all user roles—students, alumni, and administrators—have their needs
addressed through clearly defined system behavior.

2.1.1 Functional Requirements

Functional requirements define the core operations of the system—what it

should do. These are directly related to the features and functionalities
provided to different users.

4
CHAPTER 2. SYSTEM ANALYSIS 5

• Users should be able to register and log in securely.

• The system shall allow users to view, edit, and update their personal
profiles.
• Admins should be able to post news and events.
• Admins should be able to add students and handle student to alumni
transition.
• The dashboard shall display analytics on user demographics, activity,
and engagement.
• The system shall allow users to register for events.
• Users shall be able to browse news articles by category or date.
• Admins and authorized users shall be able to post job or internship
openings.
• Users shall be able to create discussion threads.
• The system shall notify users of newly added events, announcement
by sending an Email.
• Users can view event galleries, read blogs, and browse the alumni
directory.
• The system shall support online payments for event registration or
donations.
• The homepage shall provide quick navigation to major modules (Di-
rectory, Events, Blogs, etc.).
• Alumni directory shall display employment and education details.
• Student directory shall display skills and projects.
• Users shall be able to send connection or mentorship requests.

2.1.2 Non-Functional Requirements

Non-functional requirements describe how the system performs, focusing

on its quality attributes rather than behaviors.
• Data should be securely transmitted (e.g., HTTPS, JWT).
CHAPTER 2. SYSTEM ANALYSIS 6

• The system should have a user-friendly interface.

• The system should be responsive across devices.
• Optimized SQL Query for fast retrieval of data.
• The platform should support concurrent users without performance
issues.

2.1.3 User Requirements

User requirements represent what different stakeholders expect from the

system. Each user type has distinct needs and expectations:

Alumni
• Stay updated with departmental news and events.
• Reconnect with old classmates through the Alumni Directory.
• Can request to become mentors by submitting a mentor request form.
• Can be part of a forum discussion.
• Requests Letter of Recommendation from PUDoCS
Student
• Explore events and department activities through the Gallery and News
sections.
• Create and maintain digital profiles highlighting their skills, projects,
and repository links.
• Can view mentor profiles and reach out through the platform or via
provided contact links.
• Can be part of a forum discussion.
• Requests Letter of Recommendation from PUDoCS
Alumni
• Post news, blogs, and event announcements.
• Can review, approve, or reject mentor requests.
CHAPTER 2. SYSTEM ANALYSIS 7

• Moderate content submitted by users.

• Can view analytics based on alumni and student profile data.
• Handles student to alumni transitions.

2.1.4 System Requirements

These are the technical requirements needed to develop, deploy, and main-
tain the system effectively.

Hardware Requirements
• Minimum 8 GB RAM (for development and testing environments).
• Minimum 50 GB storage (for server hosting and media)
• Hosting: VPS or cloud hosting (e.g., AWS, DigitalOcean)
Software Requirements
• Operating System:GNU/Linux or Windows 10/11.
• Backend: Python 3.x, Django REST Framework.
• Frontend: React.js, Tailwindcss
• Database: MySQL
• Version Control: Git and GitLab
• Testing Tool: Insomnia for API testing
CHAPTER 2. SYSTEM ANALYSIS 8

2.2 Use Cases

Use case diagrams visually represent how users interact with a system. They
help identify key system functionalities and user roles (like alumni, students,
admins), focusing on what the system should do rather than how it’s done.

The goal is to clearly define system requirements and ensure all user inter-
actions are considered during design, making the system more user-focused
and efficient.

2.2.1 User Authentication

Actors
• User
• Computer System
Use Cases
• Register
• Login
• Details verification
• Email Verification
• Registration Confirmation
Relations
• User can register, login, and access their profile.
• Register includes verification of PU alumni/student, email verification
and registration confirmation.
• Computer System handles email verification and confirmation.
CHAPTER 2. SYSTEM ANALYSIS 9

Figure 2.1: User Authentication Use Case Diagram.

2.2.2 Profile Management

Actors
• Registered Users - Alumni, Student, Staff
• Admin
• Database System
Use Cases
• Edit Profile (add/delete education, skills, etc.)
• Change Password
• Upload Resume
• Add Blogs
• Request Mentorship / LOR
• Approval (Admin)
CHAPTER 2. SYSTEM ANALYSIS 10

Relations
• Registered users manage their profiles, upload resumes, and submit
requests.
• Admin approves mentorship, blogs, and LORs.
• System stores and manages user data.

Figure 2.2: Profile Management Use Case Diagram.

2.2.3 Admin Dashboard

Actors
• Admin
• System (Computer System)
CHAPTER 2. SYSTEM ANALYSIS 11

Use Cases
• Add Batches
• Add/Delete Students/Alumni
• Handle Student to Alumni Transition
• Content Management (Events, News, Blogs)
• Approve/Reject Requests (LOR, Mentor)
• View Analytics
• Filter User Details
Relations
• Admin manages batches, users, and transitions.
• Admin handles content and approvals.
• System supports data handling and automation.
CHAPTER 2. SYSTEM ANALYSIS 12

Figure 2.3: Admin Dashboard Use Case Diagram.

2.2.4 Job/Internship Opportunity

Actors
• Faculty
• Alumni
• Student
• System (Database)
CHAPTER 2. SYSTEM ANALYSIS 13

Use Cases
• Post Job Opportunity
• Search Job Opportunity
• View Job Opportunity
• Bookmark Opportunity
• Job Details (included in posting)
Relations
• Faculty and Alumni can post jobs.
• Students can search, view, and bookmark opportunities.
• The system manages and stores job-related data.

Figure 2.4: Job/Internship Opportunity Use Case Diagram.

2.2.5 Alumni/Student Directory

Actors
• Registered Users
• Non-Registered Users
CHAPTER 2. SYSTEM ANALYSIS 14

• System
Use Cases
• Search Alumni/Student
• View Alumni/Student Profiles
• Register/Login (included for non-registered users)
Relations
• Registered users can search and view profiles directly.
• Non-registered users must register/login before accessing profiles.
• The system manages and secures user access and profile data.

Figure 2.5: Alumni/Student Directory Use Case Diagram.

Chapter 3

System Design

We mentioned in Chapter 1 that a project report’s structure could follow

a particular paradigm. Hence, the organization of a report (effectively the
Table of Content of a report) can vary depending on the type of project
you are doing. Check which of the given examples suit your project. Alter-
natively, follow your supervisor’s advice.

3.1 UI design

A general report structure is summarised (suggested) in Table 3.1. Table 3.1

describes that, in general, a typical report structure has three main parts:
(1) front matter, (2) main text, and (3) end matter. The structure of the
front matter and end matter will remain the same for all the undergraduate
final year project report. However, the main text varies as per the project’s
needs.

3.1.1 UI design

Notice that the “methodology” Chapter of Software/Web development in

Table ?? takes a standard software engineering paradigm (approach). Al-
ternatively, these suggested sections can be the chapters of their own. Also,
notice that “Chapter 5” in Table ?? is “Testing and Validation” which is
different from the general report template mentioned in Table 3.1. Check
with your supervisor if in doubt.

3.2 Architectural design

Eq. 3.1 [note that this is an example of an equation’s in-text citation] is an

example of an equation in LATEX. In Eq. (3.1), s is the mean of elements

15
CHAPTER 3. SYSTEM DESIGN 16

Table 3.1: Undergraduate report template structure

Title Page
Abstract
Acknowledgements
Frontmatter Table of Contents
List of Figures
List of Tables
List of Abbreviations

Chapter 1 Introduction
Chapter 2 Literature Review
Chapter 3 Methodology
Main text Chapter 4 Results
Chapter 5 Discussion and Analysis
Chapter 6 Conclusions and Future Work
Chapter 7 Refection

References
End matter
Appendices (Optional)
Index (Optional)

xi ∈ x:
N
1X
s= xi . (3.1)
N i =1
Have you noticed that all the variables of the equation are defined using
the in-text maths command $.$, and Eq. (3.1) is treated as a part of the
sentence with proper punctuation? Always treat an equation or expression
as a part of the sentence.

3.3 Database Design

Figure 3.1 is an example of a figure in LATEX. For more details, check the
link:
wikibooks.org/wiki/LaTeX/Floats,_Figures_and_Captions.
Keep your artwork (graphics, figures, illustrations) clean and readable. At
CHAPTER 3. SYSTEM DESIGN 17

least 300dpi is a good resolution of a PNG format artwork. However, an

SVG format artwork saved as a PDF will produce the best quality graphics.
There are numerous tools out there that can produce vector graphics and
let you save that as an SVG file and/or as a PDF file. One example of
such a tool is the “Flow algorithm software”. Here is the link for that:
flowgorithm.org.

Main

Input

False True
If

Call

End

Figure 3.1: Example figure in LATEX.

CHAPTER 3. SYSTEM DESIGN 18

3.4 Class Diagram

Algorithm ?? is a good example of an algorithm in LATEX.

3.5 Activity Diagram

Code Listing ?? is a good example of including a code snippet in a report.

While using code snippets, take care of the following:
• do not paste your entire code (implementation) or everything you have
coded. Add code snippets only.
• The algorithm shown in Algorithm ?? is usually preferred over code
snippets in a technical/scientific report.
• Make sure the entire code snippet or algorithm stays on a single page
and does not overflow to another page(s).
Here are three examples of code snippets for three different languages
(Python, Java, and CPP) illustrated in Listings ??, ??, and ?? respectively.
Here we used the “\clearpage” command and forced-out the second
listing example onto the next page.
Chapter 4

Implementation

The results chapter tells a reader about your findings based on the method-
ology you have used to solve the investigated problem. For example:
• If your project aims to develop a software/web application, the results
may be the developed software/system/performance of the system,
etc., obtained using a relevant methodological approach in software
engineering.
• If your project aims to implement an algorithm for its analysis, the
results may be the performance of the algorithm obtained using a
relevant experiment design.
• If your project aims to solve some problems/research questions over a
collected dataset, the results may be the findings obtained using the
applied tools/algorithms/etc.
Arrange your results and findings in a logical sequence.

4.1 Implementation Design

...

19
CHAPTER 4. IMPLEMENTATION 20

4.2 Example of a Table in LATEX

Table 4.1 is an example of a table created using the package LATEX“booktabs.”

do check the link: wikibooks.org/wiki/LaTeX/Tables for more details. A
table should be clean and readable. Unnecessary horizontal lines and ver-
tical lines in tables make them unreadable and messy. The example in
Table 4.1 uses a minimum number of liens (only necessary ones). Make
sure that the top rule and bottom rule (top and bottom horizontal lines)
of a table are present.
Table 4.1: Example of a table in LATEX

Bike
Type Color Price (£)
Electric black 700
Hybrid blue 500
Road blue 300
Mountain red 300
Folding black 500
Chapter 5

Testing

Depending on the type of project you are doing, this chapter can be merged
with “Results” Chapter as “ Results and Discussion” as suggested by your
supervisor.
In the case of software development and the standalone applications,
describe the significance of the obtained results/performance of the system.

5.1 A section

The Discussion and Analysis chapter evaluates and analyses the results. It
interprets the obtained results.

21
Chapter 6

Conclusions and Future Work

6.1 Conclusions

Typically a conclusions chapter first summarizes the investigated problem

and its aims and objectives. It summaries the critical/significant/major
findings/results about the aims and objectives that have been obtained by
applying the key methods/implementations/experiment set-ups. A conclu-
sions chapter draws a picture/outline of your project’s central and the most
signification contributions and achievements.
A good conclusions summary could be approximately 300–500 words
long, but this is just a recommendation.
A conclusions chapter followed by an abstract is the last things you write
in your project report.

6.2 Future work

This section should refer to Chapter 4 where the author has reflected their
criticality about their own solution. Concepts for future work are then
sensibly proposed in this section.
Guidance on writing future work: While working on a project, you
gain experience and learn the potential of your project and its future works.
Discuss the future work of the project in technical terms. This has to be
based on what has not been yet achieved in comparison to what you had
initially planned and what you have learned from the project. Describe
to a reader what future work(s) can be started from the things you have
completed. This includes identifying what has not been achieved and what
could be achieved.
A good future work summary could be approximately 300–500 words

22
CHAPTER 6. CONCLUSIONS AND FUTURE WORK 23

long, but this is just a recommendation.

Chapter 7

Codes

Write a short paragraph on the substantial learning experience. This can

include your decision-making approach in problem-solving.
Some hints: You obviously learned how to use different programming
languages, write reports in LATEXand use other technical tools. In this sec-
tion, we are more interested in what you thought about the experience.
Take some time to think and reflect on your individual project as an expe-
rience, rather than just a list of technical skills and knowledge. You may
describe things you have learned from the research approach and strategy,
the process of identifying and solving a problem, the process research in-
quiry, and the understanding of the impact of the project on your learning
experience and future work.
Also think in terms of:
• what knowledge and skills you have developed
• what challenges you faced, but was not able to overcome
• what you could do this project differently if the same or similar problem
would come
• rationalize the divisions from your initial planed aims and objectives.
A good reflective summary could be approximately 300–500 words long,
but this is just a recommendation.

Note: The next chapter is “References,” which will be automatically

generated if you are using BibTeX referencing method. This template uses
BibTeX referencing. Also, note that there is difference between “Refer-
ences” and “Bibliography.” The list of “References” strictly only contain
24
CHAPTER 7. CODES 25

the list of articles, paper, and content you have cited (i.e., refereed) in
the report. Whereas Bibliography is a list that contains the list of articles,
paper, and content you have cited in the report plus the list of articles,
paper, and content you have read in order to gain knowledge from. We
recommend to use only the list of “References.”
References

26
Appendix A

Codes)

Some lengthy tables, codes, raw data, length proofs, etc. which are very
important but not essential part of the project report goes into an
Appendix. An appendix is something a reader would consult if he/she needs
extra information and a more comprehensive understating of the report.
Also, note that you should use one appendix for one idea.
An appendix is optional. If you feel you do not need to include an
appendix in your report, avoid including it. Sometime including irrelevant
and unnecessary materials in the Appendices may unreasonably increase the
total number of pages in your report and distract the reader.

27
Appendix B

Screenshots

...

28