Nanseera Cocis Bist

AN ALUMNI MANAGEMENT SYSTEM
By
GROUP 1
DEPARTMENT OF INFORMATION SYSTEMS

SCHOOL OF COMPUTING AND INFORMATICS TECHNOLOGY
A Project Report submitted to the School of Computing and Informatics Technology

For the Study Leading to a Project Proposal in Partial Fulfilment of the
Requirements for the Award of the Degree of Bachelor of Information Systems and
Technology of Makerere University
Supervisor
Albert George Bitwire (Mr.)
Department of Information Technology

School of Computing and Informatics Technology, Makerere University
[email protected]
Telephone: +256-41-540628 Fax: +256-41-540620
December 2020
Dedication
This report is dedicated to all the group members of GROUP 1(BIST 3, 2020) who took
off time and hardwork to make sure that this work was accomplished successfully. We
further dedicate this report to our supervisor Albert George Bitwire (Mr.) who made himself
available to us whenever we needed guidance, motivation and support. And also to the love,
support and hard work that our parents have endlessly invested and showed to us. May God
bless you all.
iii
Acknowledgement
First of all, we thank God the Almighty for blessing us with the knowledge, power and
wisdom to make our project a success and for the strength, health and will to prevail over all
the problems that would have prevented us from completing this project. Thank you Lord!
We would like to also extend our utmost gratitude to our parents for their moral and financial
support that necessitated the completion of this project. We are really grateful.
We wish to acknowledge the invaluable input of our supervisor, Albert George Bitwire (Mr.)
who always reviewed our work and suggested changes as well as advising us on new input.
His formidable efforts are highly commended. Thank you supervisor for having been patient
with us and the support you have provided us with up to the submission of this project.
In the same spirit of thanksgiving, we take this opportunity to thank the entire staff of
the School of Computing & Informatics Technology for their various contributions to this
project’s success through both technical and intellectual support all through our period of
study.
Special thanks to all our friends for their views, knowledge and opinions that concerned our
project. Their contributions were critical in providing information that made it possible to
successfully put this project together.
For all the support offered unto us, we thank you and wish God’s choicest blessings!
iv
Table of contents
Declaration i
Approval ii
Dedication iii
Acknowledgement iv
List of Tables ix
List of Figures x
List of Acroymns xii
Abstract xiii
1 Introduction 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Background to the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 Main Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.2 Specific Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6 Significance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6.1 University . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
v
1.6.2 Students . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.3 Alumni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Literature Review 5
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Existing Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 Makerere University Convocation . . . . . . . . . . . . . . . . . . . . 5
2.2.2 alumni.harvard.edu/ . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 www.manchester.ac.uk/connect/alumni/ . . . . . . . . . . . . . . . . 6
2.2.4 alumni.mku.ac.ke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.5 nus.edu.sg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.6 The University of Pretoria Convocation . . . . . . . . . . . . . . . . . 8
2.2.7 Social Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Comparison with Existing Systems . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Methodology 13
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1 Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 Review Existing Literature . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Design Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Process Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Functional Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 Data Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Rapid Application Development . . . . . . . . . . . . . . . . . . . . . 16
3.4.2 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.3 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
vi
3.4.5 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.6 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.7 Frameworks and Libraries . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 System Testing and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.2 System Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.3 Usability Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 System Study Analysis and Design 20

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2 System Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.1 Strengths of Existing Systems . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Weaknesses of Existing Systems . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 The Proposed System . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 System Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3 Requirements Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2 Process Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.3 Data Modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 System Implementation, Testing and Validation 47

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2 System Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.1 Technologies used to implement the system . . . . . . . . . . . . . . . 47
5.2.2 Security Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 User Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 System Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
vii
5.4.2 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.3 Compatibility Testing . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.4 Acceptance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5 System Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5.1 System Usefulness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.5.2 System Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6 Summary, Conclusion and Recommendations 64

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
References 65
Appendicies 67
viii
List of Tables
2.1 Comparison of the Existing Systems . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Respondents from interview sessions and questionnaires . . . . . . . . . . . 22

4.2 Software requirements of the system . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Hardware requirements of the system . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Process Modelling Symbols and their Descriptions . . . . . . . . . . . . . . . 36
4.5 Entities and their descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Processes and their descriptions . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Data stores and their descriptions . . . . . . . . . . . . . . . . . . . . . . . . 40
4.8 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1 User Satisfaction Rate with the System . . . . . . . . . . . . . . . . . . . . . 62

5.2 Usability Rate as gathered from the users . . . . . . . . . . . . . . . . . . . . 63
ix
List of Figures
4.1 Analysis of social media usage patterns according to the gender . . . . . . . 23

4.2 Analysis of Respondent’s Interest in the various Social Media Functionalities 24
4.3 Analysis of Respondents awareness (alumni) of Makerere University Projects 25
4.4 Analysis of Respondents awareness (students) of Makerere University Projects 25
4.5 Analysis of Respondents (alumni) platforms for knowing about ongoing Mak-
erere University Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6 Analysis of Respondents interest in contribution to Makerere University Projects 26
4.7 Analysis of respondents preferred modes of contributions . . . . . . . . . . . 27
4.8 Analysis of respondents interest in engagement and interaction . . . . . . . . 28
4.9 Analysis of respondents needs for Interaction and Engagement . . . . . . . . 29
4.10 Analysis of respondents recall of their student numbers . . . . . . . . . . . . 30
4.11 Analysis of respondents recall of their registration numbers . . . . . . . . . . 30
4.12 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.13 Context Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.14 Level 1 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.15 Cardinalities and their meanings . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.16 Enhanced Entity Relationship Diagram . . . . . . . . . . . . . . . . . . . . . 42
5.1 Index Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Registration Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3 Login Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.4 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.5 Messaging feature between two users. . . . . . . . . . . . . . . . . . . . . . . 52
x
5.6 Messaging feature between multiple users in a group. . . . . . . . . . . . . . 53
5.7 Pages Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.8 Jobs Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.9 Projects Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.10 Support Project Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 Confirm Payment towards a Project . . . . . . . . . . . . . . . . . . . . . . . 57
5.12 Project Update from Project Manager’s Dashboard . . . . . . . . . . . . . . 58
5.13 Admin Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
xi
List of Acroymns
BPMN Business Process Modelling Notation

CSS Cascading Stylesheets
CV Curriculum Vitae
DBMS Database Management System
DFD Data Flow Diagram
E-R Entity Relationship
HAA Harvard Alumni Association
HTML5 Hypertext Markup Language (version 5)
NUS National University of Singapore
PHP Hypertext Pre-processor
RAD Rapid Application Development
SQL Structured Query Language
UML Unified Modelling Language
xii
Abstract
Online social interactions have become a way of life. Virtual meetings and chatting are now
a large component of our social circles. These engagements have broken physical barriers
and have made communication even more seamless and better.
Sadly, these social interaction platforms haven’t been much utilised in very many institutions,
yet they come with loads of benefits.
This study is localised to Makerere University, but it’s findings are generalizable to most
institutions and the solutions provided can be customized to the various places of need.
In this study, we set out to understand the gap in the communication and interaction between
the university, it’s alumni and the students. Consequently, the main objective of this research
project was to identify the information gap between the administration, alumni and students
of Makerere University and thereafter devise solutions to this challenge.
To fully understand the problem at hand, data collection techniques such as use of question-
naires, interviews, reviewing existing literature were used. Design methods such as process
modelling, functional modelling and data modelling were used in the system analysis & de-
sign phase. The implementation was done with programming languages such as HTML5,
CSS, PHP, JavaScript and their related frameworks such as jQuery and Bootstrap.
The developed system bridges the gap between the different stakeholders by providing a
platform of engagement for information sharing, fundraising for given causes, mentorship,
real time tracking of projects and recognition for all the outstanding alumni.
xiii
Chapter 1
Introduction
1.1 Introduction
An Online Alumni Management System helps institutions to strategically build and maintain
their alumni network, by facilitating engagement, community-building, networking, commu-
nications amongst many more functionalities. And thus a secondary array of positive mar-
keting takes place. With an Online Alumni Management System, the alumni data can be
centralized and combined to use it in any future endeavours mainly donations and fundrais-
ing.
1.2 Background to the Problem

The greatest asset any Institution can have is the Alumni System. Alumni are the people
who represent the Institution in the real world. University Alumni Systems exist to promote
active and ongoing relationships between graduates and their alma mater. However, it is a
big challenge on how to enhance mentoring between alumni and current students.(Chi et al.,
2012)
Interaction between the University and students starts from the time student enrolls into
the University as a freshman over the period in which the student lives on campus. Cooper-
ation between University and students has occurred since admission until graduation. When
students graduate and then begin their work, the only thing that can make an engagement
1
to alumni is the Alumni Association. Alumni Association will serve as a bridge between the
University and Alumni.(Rattanamethawong et al., 2015)
The University means a lot to the alumni. In many ways, a University is a place that alumni
can relate to with nostalgic stories. It is where they were introduced to the “adult world”
with knowledge, guidance, and help. Many alumni are thankful for this stepping stone that
the University was for them. This relationship with the alma mater begins with each person’s
“sense of belonging”, hence individuals want to be a member of a community. A community,
like a University and an Alumni Association, is a network of individuals that share values,
norms and codes of conduct.(Frank, 2013; Toker and Kankotan, 2016)
An Alumni Association, as a community, is unique in its various relationship’s webs, and it
is this distinctiveness that offers meaning and a sense of belonging for its members, as well as
a bond with fellow members. Within the context of organizations, identity describes what
people define as central, distinctive and enduring about their organizations(Frank, 2013;
Toker and Kankotan, 2016).
Makerere University for almost a century of its lifespan has made some effort in embracing
the benefits of building a solid alumni association. these efforts haven’t yielded as much
though! It’s becoming a trend that the interactions between the University and its clients
end once the student graduates. This mode interaction is very inefficient in a number of
ways like inadequate mobilization of alumni for common causes such as community fund-
ing. The proposed system advocates for a single online forum that integrates the various
services deemed essential for efficient workflow between the University and its alumni. The
system will provide services like fundraising for University activities, communication among
members through messaging, job mart, and real time project tracking.
1.3 Problem Statement

In Makerere university, alumni activities or interactions have greatly decreased due to the
absence of a convenient platform that can bridge the gap between students, alumni and
the university. When students graduate from the university, it normally marks an end to
their interaction with the university’s activities in that when they are out in the working
2
environment in different professional careers, it makes it difficult for the university to access
them or vice versa in case of need for mentorship, funding of different university activities,
among others. As a result, the university is even unable to track its alumni in different parts
of the world yet they are very important stakeholders in the institution.
1.4 Objectives
1.4.1 Main Objective
To develop an Online Alumni Management System.
1.4.2 Specific Objectives
1. To review literature and conduct field study about the existing alumni management
systems.
2. To design an Online Alumni Management System.
3. To implement the system based on the design.
4. To test and validate the system based on the requirements.
1.5 Scope
The scope of this study was Makerere University. As one of the oldest institutions in this
country, housing students, staff and alumni from all over the world. We feel it’s feasible to
carry out the research therein. Also, to cope with constraints of financial resources and time,
Makerere University is the ideal place to carry out this research.
1.6 Significance
The system will be of a high importance to the following stakeholders;
3
1.6.1 University
The University will keep track of its alumni so as to leverage on the benefits of easier
monetary financing wherever need be. The University will also gain publicity due to its
healthy relationship with its alumni who will always passionately speak about it. They will
also track the quality of their graduates out there in the job market and therefore fine tune
the content delivered to the ongoing students.
1.6.2 Students
The students will enhance their chances of getting internships and employment opportunities
due to the connections with the alumni. They will also enhance their soft skills through
mentorship and career guidance by the alumni.
1.6.3 Alumni
The Alumni will keep connected with a batch of their old classmates so as to leverage on the
opportunities created amongst them. They will get updates of the latest information and
news from the institution.
4
Chapter 2
Literature Review
2.1 Introduction
A review of prior, relevant literature is an essential feature of any academic project. An
effective review creates a firm foundation for advancing knowledge. It facilitates theory
development, closes areas where a plethora of research exists, and uncovers areas where
research is needed.(Webster and Watson, 2002)
2.2 Existing Systems
2.2.1 Makerere University Convocation
Makerere University convocation is an association that brings together all the alumni and
current staff of Makerere University. It derives its mandate from the Universities and Other
Tertiary Institutions Act, 2001 (As Amended In, 2003 And As Amended In, 2006).
This association has an online platform where members can register. This platform offers
information about the Makerere University Convocation such as vision, mission, principles,
objectives and activities. It also allows for members to register and make donations to Mak-
erere University.
However, the online platform doesn’t allow for most of the principles of the Makerere Univer-
sity Convocation to be realised. Principles such as freedom of expression can’t be achieved
5
without a seamless mode of communication amongst the various stakeholders. Another prin-
ciple, Responsibility and accountability cannot be achieved on the current platform. All the
accountability for any project is seen only at the university and this undermines the efforts
of those outside Makerere University to track their contributions to any projects.
In addition to unrealised principles, there are functionalities that are lacking in the system.
These include; members cannot track the works of their monies on this platform(zero online
accountability), members cannot contribute to a specific cause on this platform, members
cannot interact with each other or even with students, students can only view the announce-
ments and cannot harness opportunities for mentorship etc., the alumni cannot connect with
persons that were in there classes and harness the opportunities shared with each other.
2.2.2 alumni.harvard.edu/
The Harvard Alumni Association (HAA) is an alumni association that maintains and en-
hances a highly engaged, vibrant community of the University of Harvard alumni and friends
worldwide.
The HAA helps alumni connect with the University and with fellow graduates. This is
achieved through a wealth of Club activities, continuing education programs, online ser-
vices, and alumni events around the world.
This association has an online platform on which it carries out a section of it’s activities.
These activities include bringing together alumni and associate members. Associate mem-
bers are those persons that enrolled for a certificate, degree or diploma but didn’t complete
their education. These members can contribute to the various projects at Harvard Univer-
sity. The alumni are updated about the events that are happening around the university.
However, the alumni cannot view the current progress of the projects in real time i.e. there’s
no real time accountability. The alumni cannot engage with one another or even the students.
2.2.3 www.manchester.ac.uk/connect/alumni/
”At Manchester we’re proud to have the largest global alumni community of any campus-
based university in the UK, with many of the almost 480,000 former students in more than
6
190 countries, holding top positions in every imaginable field.” a quotation from the Univer-
sity of Manchester website.
This platform doesn’t perform any alumni engagement functionality!
2.2.4 alumni.mku.ac.ke
It is an online portal for the alumni and current students of Mount Kenya University to
follow up with activities within the institution. It intends to provide up to date information
about the University to the current students, staff, alumni and the general public.
Its downside is that it is more of an abandoned project with the available information being
last updated way back in 2013. Besides, the online system provides only basic information in
form of announcements. It lacks essential features required by an effective alumni manage-
ment system like community development through alumni groups, employability features,
mentoring, member registration and digital fund raising and live interaction between mem-
bers.
Alumni societies have also recently begun working more aggressively with young alumni to
provide professional networking opportunities. Programs targeted to bring young alumni
together with a career focus, and with more established alumni, demonstrates a further ser-
vice of an association.(Smith et al., 2019)The Mount Kenya University Alumni management
system lacks possibilities of championing networking between its current students and the
alumni.
2.2.5 nus.edu.sg
This is an online alumni management system for the National University of Singapore (NUS).
It is a central point of engagement between NUS students, staff and alumni. The system
features include online event management, alumni community building, online member reg-
istration and electronic alumni card provided through a mobile application in same name of
the system. The electronic card feature is perhaps the best component of this system be-
cause it helps the alumni to get discounts whenever purchasing from selected collaborating
retailers. This is a kind of pay back to the alumni for their contribution to the institutional
7
cause.
However, this system lacks online fundraising feature that can greatly improve the benefits
derived from it by its stakeholders. Statistics show that gifts from alumni comprise 26.9%
of all gifts to higher education. Statistics also affirm that this philanthropic support often
is a critical element in institutional finance. The lack of such a vital feature from the NUS
Alumni management system constrains the financial resources the institution derives from
its alumni.
2.2.6 The University of Pretoria Convocation
This is an Alumni Association For the South African based University of Pretoria. It has an
online presence in form of online website at https://www.up.ac.za/alumni. The association
is currently headed by Dr Hans Hinner Köster whose term of office started on October 31st
2019 running through to October 30th 2024.
The online system offers a number of benefits to its alumni which include the following;
Library Access
Alumni of University of Pretoria are presented an opportunity to access the univer-
sity library resources. With an interesting quote on the platform ”Readers become
Leaders”, the alumni are offered a number of reading avenues both through online and
offline resources at specified locations of the institute. These include; an access card
giving alumni access to the pedestrian gates on the Hatfield Campus Library, access to
the Merensky and other University libraries, access to electronic journals in the Meren-
sky Library, the right to borrow up to 4 books for a period of 14 days, and Photocopies
at student tariffs. However all these benefits doesn’t come out of blue. The Pretoria
department of University Relations states that one must reach a fee of R700 per an-
num (cash or debit order of R50 per month plus library fee of R100 per annum). This
amount is basically considered a donation to the development of University projects
and thus a mode of fundraising. The annual fees are really good for the institution
but a draw back to some users as one forgetting to renew the subscription causes them
frustration when they try to access resources they have been using.
8
Career Portal
This is a center for employment resources to the alumni of the University of Pretoria. It
brings job related information to the door step of the institution’s alumni and thereby
saving them a burden of borrowing through various recruitment service providers. It
is quite secure in a way that employment opportunities are uploaded through the
portal administrator thus reducing online fraud and scam. However, the system is
lacking in a sense that potential candidates for a given job have to navigate to the
individual employer’s site to conduct the actual application for the identified opening
on the portal. The services could have been better if the alumni had an opportunity
to develop CV’s integrated within the system accounts such that the admin searches
through the alumni list, identify those qualifying for the post, notify them by email and
then whoever is interested in the post just click approval button and the application
is sent to the recruiting agency. The proposed system intends to offer such flexibility
with the goal of reliable alumni services at reduced effort and time.
Membership/ Alumni Groups

It has an integrated feature for supporting alumni groups. This allows the alumni
to connect with people of the same backgound relations with the University and also
facilitates the communication between alumni.
However the system lacks an inbuilt feature to support alumni groups as currently the groups
are supported through an integration with a private vendor called Graduway that provide
software solutions to associations.
2.2.7 Social Media
Recent events indicate that sharing news in social media has become a phenomenon of
increasing social, economic and political importance because individuals can now participate
in news production and diffusion in large global virtual communities.(Lee and Ma, 2012)
Institutions have exploited various social media platforms, but these ones listed below are
notably the most sought after sites.
9
Facebook
With over 20 million registered accounts, Institutions have opened up Facebook pages where
they pass on information to the various alumni. These pages are usually very informative!
On the downside, they are merely information sources and no monetary benefits can be
derived from them. They don’t allow for a smooth interaction between the alumni, manage-
ment and the students.
Twitter
Twitter holds more credibility that Facebook. On the light-side, it’s merely informative and
no monetary benefits can be derived from it!
Interaction is between management (administrators of the account)and whoever chooses to
engage with them.
WhatsApp
WhatsApp groups form formal communication channels and about to be endorsed by most
companies as a formal engagement platform.
These groups are very engaging and attract large audiences. On the light-side, they have a
limitation of 256 members and that’s just about one class of the entire alumni population.
Less than 5% of students from the same year!
2.3 Comparison with Existing Systems
10
System Features Makerere Uni- alumni.harvard www.manchester alumni.mku nus.edu.sg The Uni- Social Media
versity Convo- .edu/ .ac.uk/connect .ac.ke versity of
cation /alumni/ Pretoria Con-
vocation
(a)Information Sharing X X X X X X X
(b)Fundraising X X x x x X x
(c)Mentorship x x x x x x x
(d)Fundraising to a Specific x X x x x x x
11
Cause
(e)Real-time tracking of projects x X x x x x x
(f)Alumni Engagement with each x X x x x X X
other (Chatting)
(g)Alumni Badges for Outstand- x x x x x x x
ing Alumni
Table 2.1: Comparison of the Existing Systems

2.4 Conclusion
From the above comparison table, there’s just a multitude of functionality that’s missing in
the reviewed existing systems. The proposed system will eradicate/remove all the loop holes
in the existing systems.(Kajubi, 1992)
12
Chapter 3
Methodology
3.1 Introduction
This chapter consists of data collection methods, techniques and tools that were used to
realize the Proposed Online Alumni Management System’s objectives. There are various
methods that could have been employed in developing the system and these can be classified
as data collection methods, design methods, implementation and testing methods.
3.2 Data Collection

The purpose of data gathering is to collect sufficient, relevant, and appropriate data so that
a set of stable requirements can be produced.(Rogers et al., 2011) Data collection methods
focused on identifying user expectations of the system. The users of the proposed system are
students, alumni and administrators of Makerere University. The data collection methods
that were used include interviews, observation and questionnaires as explained below.
3.2.1 Questionnaires
Questionnaires are a set of open or closed ended questions administered to respondents to

gather information on a research phenomenon. Printed manual questionnaires were used for
data collection. The different stakeholders were given questionnaires with closed ended ques-
13
tions to acquire information such as their needs for the alumni system (user requirements)
during requirements collection phase.
3.2.2 Review Existing Literature
Journals, research papers, books among many more were reviewed so as to extensively un-
derstand and define the problem at hand. This literature provided us with an extensive
understanding of the subject of the study. From the recommendations from various research
papers, we got to know where to put more focus and emphasis therefore fully understanding
and getting to know the various user requirements.
3.2.3 Interviews
An interview is a conversation where questions are asked and answers are given. Through
this interaction with the various stakeholders, we were able to understand their needs for
the Proposed Online Alumni Management System.
3.3 Design Methods

System design is the process of designing the elements of a system such as the architecture,
modules and components, the different interfaces of those components and the data that
goes through that system.
3.3.1 Process Modelling
This involved graphically representing the processes, or actions, that capture, manipulate,
store, and distribute data between a system and its environment and among components
within a system. This consisted of modelling a data-flow diagram (DFD). A data-flow
diagram is a graphical illustration that shows the movement of data between external entities
and the processes and data stores within a system.
14
3.3.2 Functional Modelling
This refers to a structured representation of functions (i.e. activities, actions, processes, op-
erations) within the modelled system. The purpose of the functional model was to describe
the functions and processes, assist with discovery of information needs, help identify oppor-
tunities and establish a basis for determining the product and service costs. A functional
block diagram was used which described the functions and interrelationships of a system for
example relationships between functions, etc.
3.3.3 Data Modelling
This is the process of creating a data model for the data to be stored in a database. This
data model is a conceptual representation of data objects, associations between different
data objects, and the rules. An Entity Relationship (E-R) Model was used in this case. This
involved three different types of data models i.e. conceptual model, logical and physical
model. Graphical modelling languages included;
Unified Modelling Language (UML): To describe software both structurally and be-
haviourally with a graphical notation.
Flowchart: A schematic or stepwise representation of an algorithm.
Business Process Modelling Notation (BPMN): Used as the Process Modelling lan-
guage.
In conclusion, the Design methods that were used are as follows;
Architectural design: This describes the views, models, behaviour, and structure of
the system.
Logical design: This represents the data flow, inputs and outputs of the system. Ex-
ample: E-R Diagrams (Entity Relationship Diagrams).
Physical design: This involves how users add information to the system and how the
system relays information back to the users, how the data is modelled and stored within
15
the system, how data moves through the system, how it is validated, secured and/or
transformed as it flows through and out of the system.
3.4 Implementation
This is a process that ensures that the information system proposed and designed through
the initial life cycle phases is physically realized, is operational, satisfies user requirements
and conforms to the information systems standards and as defined by the standardization
organizations. The goal of this process was achieved through a number of techniques and
technologies. The technique that was used for implementing the proposed system is Rapid
Application Development (RAD). The technologies that were used include but are not limited
to HTML, CSS, JavaScript, MySQL, PHP and their related frameworks like jQuery and
Bootstrap.
3.4.1 Rapid Application Development
Rapid Application Development (RAD) is a team-based technique that speeds up informa-

tion systems development and produces a functioning information system quickly.(Shelly
and Rosenblatt, 2011) RAD is based on prototyping. Prototyping is a systems development
method in which a prototype is built, tested and then reworked as necessary until an accept-
able outcome is achieved from which the complete system can be developed. This technique
helped us to realize the implementation of the Proposed Online Alumni Management System
by partially developing and implementing prototypes until the complete acceptable system
was reached.
3.4.2 HTML5
This stands for Hypertext Markup Language (version 5). The language provides a stem to
any online system that uses the World Wide Web. This was used to implement a skeleton
of the Proposed Online Alumni Management System following its semantics and syntax.
16
3.4.3 CSS
This refers to Cascading Stylesheets and it is a language used together with HTML5 to
provide design to the skeleton created in HTML5. This was used to implement the User
Interfaces as derived from the design prototypes of the system design phase for the Proposed
Online Alumni Management System.
3.4.4 JavaScript
This is a client-side scripting language popularly used in developing online systems and
applications. JavaScript is essential in this field due to its strength in adding motion to the
static HTML5 and CSS. JavaScript was to support front end flexibility by enabling some
activities and processing to be handled at the client level such as validating user input.
3.4.5 MySQL
This an open source database management system (DBMS) that is widely used in systems
that require backend storage mechanisms for the system data. The DBMS implements a
language called Structured Query Language (SQL) which controls the interactions between
the backend data storage facilities and the clients that utilizes the stored resources. Due to
the fact that the Proposed Online Alumni Management System shall be a dynamic system
that relies on the database system, MySQL was vital in offering services required by the
system to support the user needs.
3.4.6 PHP
This stands for Hypertext Pre-processor. It is server-side scripting language that is responsi-
ble for executing scripts regarding user requests at the server side and delivering the processed
output as a response to the client. PHP was used to support the processing activities that
calls for interaction with the database management system like storing and manipulating
system data.
17
3.4.7 Frameworks and Libraries
As we had chosen rapid application development as a model for implementing the Proposed
Online Alumni Management System, we highly depended on a number of existing frame-
works and libraries related to the above stated languages. This enabled us to shorten the
development period and ensure that the project success was achievable within the shortest
time possible. Some of the frameworks we used are;
Bootstrap. This is a CSS framework with already defined layout templates that can
be applied to any online system. It helped us to reduce the interface design duration
as designs weren’t written from scratch but rather derived from modifying Bootstrap
templates to suit our needs.
JQuery. This framework is intended to reduce the cumbersomeness of writing plain

JavaScript codes. It implements a variety of JavaScript functions that can be easily
applied and invoked in a system with just a few lines of code. This significantly reduced
on the time invested in writing JavaScript during the implementation of the proposed
system.
3.5 System Testing and Validation

Testing was done according to the requirement specification and test cases which covered all
the crucial services required. The different tests included; unit testing, system integration
testing and usability testing.
3.5.1 Unit Testing
This tests the internal structures or workings of an application. Each activity was first
tested individually to ensure that it is working. Internal perspective of the system as well
as programming skills, were used to design test cases.
18
3.5.2 System Integration Testing
The individual program units (application interfaces) representing the components of our
system were combined and tested as a whole to ensure that the software requirements were
met. The application was then be tested by the different stakeholders (user acceptance
testing).
3.5.3 Usability Testing
The system was then rolled out to the different users so that they ensure that the functionality
they requested for in the requirements collection phase had been implemented. They also
provided feedback on the general feel and usage of the system.
19
Chapter 4
System Study Analysis and Design
4.1 Introduction
This chapter explains the results gathered from the field and analysing of the current sys-
tems for their weaknesses. It also points out how the Alumni Management System helps
scale down these challenges. It also highlights the system requirements, analysis and design
methodologies.
4.2 System Study

All through our research, we used a mix of research methods to collect the data. These
included questionnaires, interview guides and review of existing literature. Questionnaires
were given to the students and alumni as they are important stakeholders. Interview guides
were used for data collection from the Makerere University Administrators we interacted
with.
4.2.1 Strengths of Existing Systems
Below are the strengths of the existing systems:
Information Sharing. All the reviewed platforms enable information sharing from the
university to the alumni of the various institutions.
20
Fundraising. To some extent, some of the systems enable fundraising for certain
projects.
Alumni engagement with each other. Some of the systems reviewed enable their alumni
to interact with one another on those university platforms or via social media chat-
rooms.
Real time tracking of projects is offered in some of the reviewed projects.
4.2.2 Weaknesses of Existing Systems
Below are the weaknesses of the existing systems:
Inability to fundraise for a special cause. Much as some of the systems support fundrais-
ing, the support is really rudimentary. This limits contributions for people who only
wish to contribute to specific causes. This is due to the fact that naturally, we all have
biases! Someone will easier contribute to a project they feel a more part of rather than
just any project there is!
Inability to offer mentorship. Person to person messaging is more possible on the social
media. Establishing a connection with someone to mentor is difficult because you may
not have a central point of connectivity. This functionality is missing out in most of
the reviewed systems.
In most of the reviewed systems, there isn’t functionality to support internship or job
opportunities. This functionality is very important especially in such times when levels
of unemployment keep rising!
Most notable and outstanding alumni are listed by Google, but not necessarily by the
systems reviewed. Such recognition is an inspiration to others hence the need for such
functionality.
21
4.2.3 The Proposed System
The Alumni Management System extends the strengths of the existing systems. It offers
functionalities to that address the weaknesses of the existing systems. It even offers more
functionality such as support for real time contributions with mobile money, one of the most
convenient modes of payment in Uganda.
4.3 System Analysis
4.3.1 Data Collection
As researchers, we applied both qualitative and quantitative research techniques in the col-
lection and analysis of the data. Data was collected from the central region with the focus
on Kampala district and the Greater Kampala area of Wakiso and Mukono. Questionnaires
and interview guides were used to collect data from people. This data was later subjected
to quantitative analysis. Using descriptive statistics, on the other hand, an interview guide
was carefully designed to capture opinionated views from respondents.
Using a purposive sampling technique, 150 respondents were selected to respond to question-
naires, a total of 100 questionnaires were given out and 95 were returned manually and out
of which 5 questionnaires were incomplete and inconsistent. For the online questionnaires,
50 questionnaires were sent out by email, 36 responses were recorded and out of which 6 had
inconsistent data. The questionnaires with incomplete and inconsistent data were removed
during data cleaning phase. Below is table showing a breakdown of the sample size.
Questionnaire respondents
Region Number of respondents Sampling method
Central 120 Purposive Sampling
Interviews
Central 5 Purposive Sampling
Total 125
Table 4.1: Respondents from interview sessions and questionnaires
22
The data was coded and entered in SPSS and analyzed using SPSS’ descriptive statistics i.e.
percentages, means and frequencies to extract the most important information about the
proposed system.
4.3.2 Data Analysis
Analysis of Respondent’s Gender Against the Social Media Platforms

75
Male
70 Female
65
60
Number of respondents
55
50
45
40
35
30
25
WhatsApp FaceBook Twitter Instagram SnapChat

Social Media Platform
Figure 4.1: Analysis of social media usage patterns according to the gender
From the figure above, we observed that female respondents used SnapChat and Instagram
more while their male counterparts tilted more towards Twitter and FaceBook. The usage
of WhatsApp was fairly the same for both genders.
23
Analysis of Respondent’s Interest in the various Social Media Functionalities
100
Alumni
Students
90
80
70
60
50
40
30
20
10
Chatting Jobs Educational Purposes Blogging Others

Social Media Functionality
Figure 4.2: Analysis of Respondent’s Interest in the various Social Media Functionalities
From the above graph, we realized that almost all respondents were interested in chatting,
jobs were more preferred by the alumni, educational interactions were more preferred by
students and blogging was an interest by almost half of either alumni or staff.
24
Analysis of Respondents awareness of Makerere University Projects
13%
Aware
UnAware
87%
Figure 4.3: Analysis of Respondents awareness (alumni) of Makerere University Projects

From the figure above, results indicated that most respondents (alumni) were not aware of
projects going on inside Makerere University.
Respondents in the student category were aware of some of the projects because they’ve
viewed some of those as they are at campus almost all the time. The results are shown
below.
8%
Aware
UnAware
92%
Figure 4.4: Analysis of Respondents awareness (students) of Makerere University Projects
25
Analysis of Respondents platforms for knowing about ongoing University Projects
5%
10%
Social Media
University Website
55% Peers
30% Others
Figure 4.5: Analysis of Respondents (alumni) platforms for knowing about ongoing Makerere
University Projects
From the above figure, we observe that most respondents came to know about University
Projects from social media as compared to the other platforms.
Analysis of Respondents interest in contribution to Makerere University Projects
8%
Interested
Not-interested
92%
Figure 4.6: Analysis of Respondents interest in contribution to Makerere University Projects

From the figure above, we observed that most respondents were willing and had interest in
contributing to Makerere University Projects.
26
Analysis of Respondents preferred modes of contributions to Makerere Projects
120
110
100
90
80
70
60
50
40
30
Physical Items Mobile Money Banking
Modes of Contribution
Figure 4.7: Analysis of respondents preferred modes of contributions

From the above figure, the respondents preferred mobile money as a mode of payment as
compared to other options. There was also interest in banking and delivery of physical items
for the projects.
27
Analysis of Respondents interest in engagement and interaction
5%
Interested
Not-interested
95%
Figure 4.8: Analysis of respondents interest in engagement and interaction

From the figure above, the respondents showed enormous interest in interacting and engaging
with one another. They provided reasons for the high interest and were analysed in the
following section.
28
Analysis of Respondents Needs for Interaction and Engagement
Students
Alumni
90
80
70
60
50
40
30
Mentorship Internship/Jobs Causal Chatting

Interaction Needs
Figure 4.9: Analysis of respondents needs for Interaction and Engagement

From the figure above, respondents in the student category were interested in these interac-
tions because of internship opportunities majorly. Mentorship was also highly sought after
and causal chatting being the least need for interaction.
Respondents from the alumni category preferred causal chatting as compared to other needs.
There was interest in jobs as well, but little interest in mentorship.
29
Analysis of Respondents Recall of their student & registration numbers
10%
Recall
Forgot
90%
Figure 4.10: Analysis of respondents recall of their student numbers

From the figure above, 90% of respondents in the alumni category had the ability to recall
their student numbers. The recall rate for registration numbers was rather lower as shown
in the figure below.
Recall
45% Forgot
55%
Figure 4.11: Analysis of respondents recall of their registration numbers
4.3.3 Requirements Analysis
In the previous section, data analysis was done. In this section, user, functional, non-
functional and system requirements were derived from the analysed data.
30
User Requirements
The are three groups of users:
System Administrators: They have a higher understanding of how the system

works. System administrators also have more privileges compared to other users.
Project Managers: They have priveleges that allow them to update project’s progress
such that the users of the system know what’s on ground in real time.
Registered Users: They are categorized into alumni and students. Alumni are the
former students of the institution.
Functional Requirements
These requirements describe what the system should do basing on the actors’ possible actions.
The functional requirements of the system include:
The registration module should be able to allow all new users to register so as to create
accounts.
The authentication module should be able to allow registered users to login to their
created accounts.
The messaging module should allow registered users to interact with each other.
The messaging module should allow registered users to create groups for interaction
with peers.
The mentorship module should allow registered users to be mentored.
The jobs system should allow posting of job and internship offerings.
The blogging module should allow registered users to create and read blogs.
The project management module should allow project managers to update information
about the project such as when a particular project is completed.
31
The project management module should allow registered users to view and make con-
tributions to projects.
The financial module should be able to facilitate contributions to projects through

mobile money.
The administration module allow the administrator to manage users and perform other
administrative tasks.
Non-functional requirements
These requirements specify the criteria that can be used to judge the operation of a system
rather than specific behaviour. They define system properties and the constraints of the
system. The system must show software quality attributes such as accuracy, performance,
cost, security, modifiability and usability. The non-functional requirements include:
The system must provide logon security at the application level.
The system should process user queries and return responses in 30 seconds.
The system must be operational seven days a week, 365 days a year.
The system should be responsive that is to say, it should provide immediate feedback
to the users.
The system should provide forms of data capture during registration and login in.
The system should be easy to maintain and adoptable to users.
All transactions must have audit trails.
The system must create an error log file that includes the error type, description, and
time.
32
Software Requirements
Compatibility is a requirement to ensure that our system has the ability to run and perform
its required tasks properly. The table below points out the minimum requirements for the
system.
Software Minimum System Requirements

Operating system All Windows Operating Systems and some distros of Linux e.g.
Ubuntu
Database SQLite and MySQL
Browser Google Chrome, Mozilla fox, Opera mini, Edge
Security System authentication
Table 4.2: Software requirements of the system
Hardware Requirements
The system required performing its required tasks properly on hardware facilities. We car-
ried out research in various areas using different kinds of hardware facilities like laptops,
smartphones and desktops to ascertain the right hardware for optimal system performance.
Hardware Minimum System Requirements

RAM 2GB
Disk Space 10GB
Table 4.3: Hardware requirements of the system
4.4 System Design

The purpose of the systems design phase is to create a physical model that will satisfy all
documented requirements for the system. (Rogers et al., 2011) In this section, requirements
were transformed into conceptual designs for the system. Data Flow Diagrams were used
33
for process modelling and Enhanced Entity Relationship Diagrams were used for the data
modelling.
4.4.1 System Architecture
Figure 4.12: System Architecture
Users: Make requests to the server and recieve responses.

Web Server: Hosts the application’s various layers which are:
Presentation Layer: Users interact with the application through the presentation
layer (web browsers).
Application Layer: Implements the business logic. Interacts with the data layer to
process requests and responses.
34
Data Layer: Handles domain data and provides persistence and retrieval services for
the database.
Database: For data storage.

Web Services: Interaction with other applications.
4.4.2 Process Modelling
Process modelling aims at representing the processes which capture, manipulate, store and
distribute data. We used a context diagram and a level 1 data flow diagram DFD to illustrate
the activities. A data dictionary was created to define the processes identified during process
modelling. These are the symbols used during process modelling.
35
Symbol Name Description
Entity Shows the different entities of the sys-
tem
Process Shows the different processes in the

data flow
Data Store It holds and stores data that has been

collected.
Repeated Entity It shows a recurrent entity
Data flow It shows the direction to which different

information is moving.
Bi-directional It shows information moving both ways

data flow
Table 4.4: Process Modelling Symbols and their Descriptions
36
Context Diagram
A context diagram shows how different actors interact with the system. It is a simple data
flow diagram that shows an abstract flow of information between the system and the various
entities.
Figure 4.13: Context Diagram
Level 1 Data Flow Diagram
Level 1 DFD is more detailed than the context diagram. It shows a detailed flow of informa-
tion between the system processes, data stores and entities. The entities in the first diagram
remain constant but the diagram is expanded into close-ups showing data stores and flows.
37
Figure 4.14: Level 1 Data Flow Diagram
38
Data Dictionary for the DFD
The data dictionary contains descriptions of processes, data stores and the external entities
identified during process modelling.
Entity Description
User A user is of the system can perform the following tasks:
Register create an account
Log onto the system
Interact and engage through forums, stories and messaging
View and contribute towards projects
Administrator An administrator manages and performs the following tasks:
Log onto the system
Post projects
Manages security and backs up system data
Project Manager A project Manager provides real time updates on projects they
are responsible for.
Mobile Money API Platform for issuing all payments made on the system.
Table 4.5: Entities and their descriptions
39
Process Description
verifyUser Verifies a user trying to register for a user account onto the system
manageProject Concerned with addition and updating of projects
authenticateAdmin Confirms that an admnistrator has authority to access the sys-
tem.
authenticateUser Confirms that a user has authority to access the system.
Register Registers a system user
manageForum Concerned with creation, joining and interaction in a forum
manageTransaction Concerned with acceptance, initiation and verification of trans-
actions
manageBlog Concerned with creation, publishing and interaction over a blog
manageStories oncerned with creation, publishing and interaction over a story
Messenger Concerned with sending and receiving of messages.
Table 4.6: Processes and their descriptions
Data stores Description

Users Stores user data
Project Stores project details
Forums Stores forums and their details
Payment Stores payment information
Donation Stores donation information
Blogs Stores blog information
Story Stores information about stories
Message Stores messages
Table 4.7: Data stores and their descriptions
40
4.4.3 Data Modelling
This section consists of all the methodologies used to come up with the conceptual design of
the system. It involves identifying the system requirements and deriving entities and their
associated cardinalities and their meanings.
Figure 4.15: Cardinalities and their meanings
41
Enhanced Entity Relationship Diagram
Figure 4.16: Enhanced Entity Relationship Diagram
42
Database Design
Below is the database design.
Table Attribute Key Null

userID PK Not
Username None Not
userPassword None Not
User userEmail None Not
userContact None Not
UseruserID None Not
Badgeid None Not
id PK Not
Alumnus studentNumber FK Not
GraduationYear None Not
id PK Not
badgeType None Not
Badge
reason None Not
awardedDate None Not
id PK Not
createdDate None Not
Blog
content None Not
useruserID FK Not
id PK Not
grantedDate None Not
Certificate
certificateType None Not
useruserID FK Not
id PK Not
College collegeName None Not
schoolID FK Not
43
id PK Not
Stories FK Not
Comment UserId FK Not
content None Not
commentDate None Not
donationID PK Not
amount None Not
Donation
Message None Not
UserID FK Not
id PK Not
Forum createdDate None Not
title None Not
id PK Not
name None Not
Group url None Not
image None Not
userID PK,FK Not
Group User
groupID PK,FK Not
id PK Not
Hall
hallName None Not
id PK Not
pageID FK Not
questions None Not
jobTitle None Not
Job
postedDate None Not
Requirements None Not
jobStatus None Not
applyDeadline None Not
44
messageID PK Not
userID1 FK Not
messageBody None Not
Message
userID2 FK Not
status None Not
sentDate None Not
id PK Not
UseruserID FK Not
name None Not
Page
category None Not
url None Not
ID PK Not
amount None Not
Payment
Message None Not
UserID FK Not
ID PK Not
name None Not
Program schoolID None Not
courseUnit None Not
studentID FK Not
ID PK Not
name None Not
Project
Status None Not
completed FK Not
userID PK,FK Not
Project Manager
projectID PK,FK Not
45
id PK Not
name None Not
Reaction emojiIcon None Not
reactedDate None Not
userID FK Not
schoolID PK Not
School name None Not
collegeID FK Not
id PK Not
position None Not
Staff
role None Not
status None Not
storyID PK Not
storyBody None Not
Story storyTitle None Not
storyStatus None Not
userID FK Not
studentNumber PK Not
hallID FK Not
registrationNumber None Not
Student
admissionYear None Not
studyLevel None Not
programId FK Not
id PK Not
forumID FK Not
Thread
title None Not
startDate None Not
Table 4.8: Database Design
46
Chapter 5
System Implementation, Testing and

Validation
5.1 Introduction
This chapter elaborates how the design of the system was implemented according to the
Project Methodology presented in Chapter 3. It also has the screenshots that give a brief
overview of how the system operates and also the system testing & validation activities.
5.2 System Implementation

In this section, we discuss the actual development of the system.
5.2.1 Technologies used to implement the system
The system was developed with a mix of web programming languages. These included PHP
for server side programming. SQL was used for developing the database. HTML5, CSS and
JavaScript were used for client side processing. Frameworks such as Bootstrap and JQuery
were also used to enforce the Rapid Application Development as they drastically reduce the
development time.
47
5.2.2 Security Implementation
Privacy was implemented with a strong authentication system that encrypts passwords by
hashing them there by preventing them from being accessed by anyone using the system.
5.3 User Interface Design

This section shows screenshots of the key features of the system and descriptions of their
functionalities.
Index Page
This is the first page the user interacts with the first time they search for the system in the
web browser.
Figure 5.1: Index Page
48
Registration
New users need to register so as to access all the functionalities that the system provides to
them.
Figure 5.2: Registration Form
49
Login
Through this interface, an already registered user can access the system.
Figure 5.3: Login Form
50
Home Page
After a user has successfully logged into the system, this is the page they first interact with.
can access the system. This page gives the user access to all the functionalities according to
their privilege level.
Figure 5.4: Home Page
51
Messaging
Through the messaging feature, a user can interact with any other user of the system on a
personal level.
Figure 5.5: Messaging feature between two users.
Users can also create or join groups and interact with each other.
52
Figure 5.6: Messaging feature between multiple users in a group.
53
Pages
On here, a user can create a page or access pages created by other users. It’s through the
page feature that a user can post a job offering.
Figure 5.7: Pages Screen
54
Jobs
Here, a user can access all the jobs that have been posted on the platform and apply for any
of those they are interested in.
Figure 5.8: Jobs Screen
55
Projects
On this page, a user access the projects that have been undertaken by the institution.
Figure 5.9: Projects Screen
The user can contribute to a project by clicking on the support project button.
56
Figure 5.10: Support Project Screen
A user can confirm the transaction from their mobile phone.
Figure 5.11: Confirm Payment towards a Project
57
Project Management Dashboard
Here, the project manager interacts with the system. They provide updates that are broad-
cast to other users after any project milestone is achieved.
Figure 5.12: Project Update from Project Manager’s Dashboard
Admin Dashboard
On this screen, the administrator is offered the functionality to manage users and perform
other admnistrative tasks.
58
Figure 5.13: Admin Dashboard
5.4 System Testing

No matter how carefully a system is designed and implemented, problems can occur. Rigor-
ous testing can detect errors during implementation(Rogers et al., 2011). The main objective
of the testing process was to uncover the errors in the system. This errors would later be
corrected through the debugging process.
5.4.1 Unit Testing
The testing of an individual program or module is called unit testing. The objective is
to identify and eliminate execution errors that could cause the program to terminate ab-
normally, and logic errors that could have been missed during desk checking(Rogers et al.,
2011). This testing was done as the team traversed through the coding phase. Every finished
module of functionality was tested just after completion to enable early debugging.
59
5.4.2 Integration Testing
Testing two or more programs that depend on each other is called integration testing accord-
ing to Rogers et al. (2011). This was carried at the integration of the different subsystems.
The aim of the integration test was to ensure that the various subsytems functioned as
expected upon integration.
5.4.3 Compatibility Testing
This test was done to establish how the system appears on devices with different screen sizes.
We established that the system scales well to the different displays (small, medium, large
and extra large interfaces).
5.4.4 Acceptance Testing
An acceptance test includes all typical processing situations. During an acceptance test, users
enter data, including samples of actual, or live data, perform queries, and produce reports
to simulate actual operating conditions. All processing options and outputs are verified by
users and the IT project development team to ensure that the system functions correctly
(Rogers et al., 2011). This test was carried with various users of the system. After user
recommendations and suggestions were picked, changes were made to provide the system
users with the interfaces and functionality they highlighted.
5.5 System Validation

The system was checked to ensure that it does exactly what it was designed to do. This
involved having a group of end users interact with it so as to assess the system accuracy and
usability to ensure system completeness. The respondents in this section were selected using
purposive sampling. These involved students and alumni of Makerere University.
60
5.5.1 System Usefulness
This was carried out to assess how much the system users were satisfied with the system
with regards to the functionality the system offers.
Question: Having interacted with the system, how useful is the Alumni Management Sys-
tem in providing the following functionality to it’s users?
61
Option Answer Percentage (%)
Information Sharing Very useful 85
Fairly useful 10
Could be useful 5
Not at all useful 0
Fundraising Very useful 90

Fairly useful 5
Could be useful 5
Not at all useful 0
Mentorship Very useful 80

Fairly useful 15
Could be useful 5
Not at all useful 0
Real-time tracking of projects Very useful 95

Fairly useful 3
Could be useful 2
Not at all useful 0
Engagement with one other Very useful 97

Fairly useful 3
Could be useful 0
Not at all useful 0
Table 5.1: User Satisfaction Rate with the System
62
Most of the respondents (more than 85%) were positive that the system would provide all it’s
intended functionality i.e. information sharing, engagement, real time tracking of projects,
mentorship and fundraising. However, some people thought that the functionality for all of
it to be utilised by any particular user.
5.5.2 System Usability
Usability refers to the degree to which a system assists the people using it to accomplish a
task. This was used to check whether the system interface is easy to navigate.
Question Answer Percentage(%)

Do you find the interface easy to Yes 95
navigate ? Fair 5
No 0
Table 5.2: Usability Rate as gathered from the users
95% of the respondents found it very easy to navigate through the system. 5% found it
fairly easy to navigate and none of the respondents found a hard time navigating through
the system.
63
Chapter 6
Summary, Conclusion and

Recommendations
6.1 Introduction
This chapter concludes the report by highlighting the achievements, outlining the challenges
encountered during the development and suggesting recommendations regarding this project.
6.2 Achievements
We were able to achieve the following objectives:
Engagement through private and group messaging.
Information Sharing through the various avenues on the platform.
Mentorship through engagement.
Fundraising through support of projects and donations.
Real time tracking of projects.
64
6.3 Challenges
As much as we were able to obtain the above stated achievements, we encountered several
challenges as discussed below:
The COVID-19 pandemic was by far the largest challenge that befell us. It’s effects
brought about delays in meeting the deadlines and schedules. There was a time of
uncertainty where this project was abandoned to almost 100% because we were trying
to survive. It’s has really been God’s grace coming thus far.
As students, our resources are really constrained. We faced enormous financial chal-
lenges during the data collection, printing and binding of the work and also high data
costs as we tried to improvise and work through the pandemic.
During data gathering, some respondents were reluctant and biased to provide infor-
mation needed for the development of the system.
This project is run along other courseunits. Establishing a balance between the project
and the other courseunits was always a challenge!
6.4 Recommendations
Areas for future research include addition of more features as future researchers may find
out from the users of the system. Also, future research into a mobile application for the
same purpose can be undertaken.
6.5 Conclusion
An Alumni Management System was successfully designed and implemented to provide func-
tionalities such as mentorship, fundraising, engagement, real time tracking of projects and
information sharing. We found a gap in the communication and interaction among the var-
ious stakeholders in Makerere University and we sought after solutions for that gap. We
undertook this endeavour successfully!
65
References
Chi, H., Jones, E. L., and Grandham, L. P. (2012). Enhancing mentoring between alumni
and students via smart alumni system. Procedia Computer Science, 9:1390–1399.
Frank, T. (2013). Reaching out to university alumni through social media - alumni depart-
ments turn to facebook, youtube, twitter and more, to engage alumni.
Kajubi, W. S. (1992). Financing of higher education in uganda. Higher Education, 23(4):433–

441.
Lee, C. S. and Ma, L. (2012). News sharing in social media: The effect of gratifications and
prior experience. Computers in human behavior, 28(2):331–339.
Rattanamethawong, V., Sinthupinyo, S., and Chandrachai, E. A. (2015). An innovation

system that can quickly responses to the needs of students and alumni. Procedia-Social
and Behavioral Sciences, 182:645–652.
Rogers, Y., Sharp, H., and Preece, J. (2011). Interaction design: beyond human-computer
interaction.
Shelly, G. B. and Rosenblatt, H. J. (2011). Systems analysis and design. Cengage Learning.
Smith, E., Gearhart, G., and Miller, M. (2019). Understanding alumni relations programs
in community colleges. International Journal of Higher Education, 8:176.
Toker, A. and Kankotan, E. (2016). Member relationship management in nonprofit organi-

zations: The case of an alumni organization.
66
Webster, J. and Watson, R. T. (2002). Analyzing the past to prepare for the future: Writing
a literature review. MIS quarterly, pages xiii–xxiii.
67
Appendicies
68
Alumni Management System Student Questionnaire
Alumni Management System Student

uestionnaire
Dear Sir/Madam, you have been randomly chosen as a respondent in a study which is
undertaken as an educational research by Makerere University, College of Computing and
Information Science Students to gain a deeper insight into the alumni engagement of
Makerere University. We appreciate your time and willingness to participate in this survey. We
pledge full anonymity of your responses!
Interaction and Makerere University Projects
Understanding you
1. Your gender is:-
Mark only one oval.
Female
Male
Prefer not to say
2. What is your Year of Study?
Mark only one oval.
Year 1
Year 2
Year 3
Year 4
Year 5
https://docs.google.com/forms/d/1yF2j8TAVWpF3t9Idlz6xMBcSArynrMMapPwbWcsRUcI/edit 1/6
3. What is your college?
Mark only one oval.
COCIS
COBAMS
CEES
CAES
CONAS
COVAB
CHUSS
CHS
School of Law
Interactions and Engagement

Please help us understand how you usually associate with your peers through answering of the following
questions.
4. Do you use social media site(s) i.e. FaceBook, Twitter, WhatsApp, LinkedIn etc. ?
Mark only one oval.
Yes
No
5. If YES, which of the following sites do you use? (Tick all applicable)
Check all that apply.
Facebook
WhatsApp
Twitter
LinkedIn
Snapchat
Instagram
Other:
6. If your answer in Question Two was "yes", which of the following best represents the site
features you often use?
Chatting
Jobs (Search and/or Apply)
Educational Purposes
Blogging
Other:
Makerere University Projects

In this section, we try are probing for information concerning any projects that are going in Makerere University
and your knowledge about them.
7. As a Makerere University Student, do you know any on-going, completed or proposed

University projects?
Mark only one oval.
Yes
No
8. If your answer above is YES, please indicate some of those projects below.
9. Would you consider contributing to any of those projects?
Mark only one oval.
Yes
No
10. If YES, do you know of any platform that you can use to contribute to these projects?
Mark only one oval.
Yes
No
11. If YES, what are the platforms you can use to contribute to these projects?
12. If NO, how would you prefer to contribute to these projects?
In kind (physical items)

Mobile Money
Through a financial institution (bank, microfinance)
Other:
In this section, we are seeking information about your engagement with the various
Alumni alumni of Makerere University.
Engagement
13. Have you interacted with any alumni of Makerere University?
Mark only one oval.
Yes
No
14. If YES, in what ways did you interact with them?
Physically
Social media
Other:
15. Why did you interact with them?
Mentorship
Internship
Chatting
Other:
16. If NO, would you want to interact with the alumni of Makerere University?
Mark only one oval.
Yes
No
17. If YES, why would you want to interact with them?
Mentorship
Employment
Have a casual conversation
Other:
Thank you for your responses!

We pledge full anonymity!
This content is neither created nor endorsed by Google.
Forms
Alumni Management System Alumnus Questionnaire
Alumni Management System Alumnus

uestionnaire
Dear Sir/Madam, you have been randomly chosen as a respondent in a study which is
undertaken as an educational research by Makerere University, College of Computing and
Information Science Students to gain a deeper insight into the alumni engagement of
Makerere University. We appreciate your time and willingness to participate in this survey. We
pledge full anonymity of your responses!
Engagement and Makerere University Projects
Understanding you
1. Your gender is:-
Mark only one oval.
Female
Male
Prefer not to say
2. What was your Year of Graduation?
3. What course did you pursue?
4. Do you remember your registration number?
Mark only one oval.
Yes
No
https://docs.google.com/forms/d/1bsIoThjlVbv2dfnoP-71gWt71vARccfzLE4-JXA3dJg/edit 1/6
5. Do you recall your student number?
Mark only one oval.
Yes
No
Interactions and Engagement

Please help us understand how you usually associate with your people through answering of the following
questions.
6. Do you use social media site(s) i.e. FaceBook, Twitter, WhatsApp, LinkedIn etc. ?
Mark only one oval.
Yes
No
7. If YES, which of the following sites do you use? (Tick all applicable)
Facebook
WhatsApp
Twitter
LinkedIn
Snapchat
Instagram
Other:
8. If your answer in Question Two was "yes", which of the following best represents the site
features you often use?
Chatting
Jobs (Search and/or Apply)
Educational Purposes
Blogging
Other:
Makerere University Projects

In this section, we are probing for information concerning any projects that are going in Makerere University
and your knowledge about them.
9. As a Makerere University Alumnus, do you know any on-going, completed or proposed

University projects?
Mark only one oval.
Yes
No
10. If your answer above is YES, please indicate some of those projects below.
11. How did you know about these projects?
Mark only one oval.
Social Media
University website
Peers
Other:
12. Would you consider contributing to any of those projects?
Mark only one oval.
Yes
No
13. If YES, do you know of any platform that you can use to contribute to these projects?
Mark only one oval.
Yes
No
14. If YES, what are the platforms you can use to contribute to these projects?
15. If NO, how would you prefer to contribute to these projects?
In kind (physical items)

Mobile Money
Through a financial institution (bank, microfinance)
Other:
In this section, we are seeking information about your engagement with the various
Alumni alumni of Makerere University.
Engagement
16. Have you interacted with any alumni of Makerere University?
Mark only one oval.
Yes
No
17. If YES, in what ways did you interact with them?
Physically
Social media
Other:
18. Why did you interact with them?
Mentorship
Job opportunities
Chatting
Other:
19. If NO, would you want to interact with the alumni of Makerere University?
Mark only one oval.
Yes
No
20. If YES, why would you want to interact with them?
Mentorship
Employment
Have a casual conversation
Other:
Thank you for your responses!

We pledge full anonymity!
This content is neither created nor endorsed by Google.
Forms
Interview guide for the Makerere University Convocation Office Staff
What’s your level of satisfaction with the convocation system?
How does it perform in terms of it’s required functionality i.e. bring together alumni
to contribute for projects?
How is the data on that platform tracked and updated?
What sort of engagement do you envision for another system?
How is accounting done to people who use the platform to send money?
Are there even people who send you money?
How would they best send in their contributions?
How would they be appreciated?
Do you think they want to be recognized?
How would they be best recognized?
81

Nanseera Cocis Bist

Uploaded by

Copyright:

Available Formats

Nanseera Cocis Bist

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nanseera Cocis Bist

Uploaded by

Copyright:

Available Formats

AN ALUMNI MANAGEMENT SYSTEM

DEPARTMENT OF INFORMATION SYSTEMS

A Project Report submitted to the School of Computing and Informatics Technology

Department of Information Technology

List of Acroymns xii

4 System Study Analysis and Design 20

5 System Implementation, Testing and Validation 47

6 Summary, Conclusion and Recommendations 64

2.1 Comparison of the Existing Systems . . . . . . . . . . . . . . . . . . . . . . . 11

4.1 Respondents from interview sessions and questionnaires . . . . . . . . . . . 22

5.1 User Satisfaction Rate with the System . . . . . . . . . . . . . . . . . . . . . 62

4.1 Analysis of social media usage patterns according to the gender . . . . . . . 23

5.1 Index Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

BPMN Business Process Modelling Notation

1.2 Background to the Problem

1.3 Problem Statement

1.4.1 Main Objective

To develop an Online Alumni Management System.

1.4.2 Specific Objectives

2. To design an Online Alumni Management System.

3. To implement the system based on the design.

4. To test and validate the system based on the requirements.

2.2 Existing Systems

2.2.1 Makerere University Convocation

2.2.6 The University of Pretoria Convocation

 Membership/ Alumni Groups

2.2.7 Social Media

2.3 Comparison with Existing Systems

Table 2.1: Comparison of the Existing Systems

3.2 Data Collection

Questionnaires are a set of open or closed ended questions administered to respondents to

3.2.2 Review Existing Literature

3.3 Design Methods

3.3.1 Process Modelling

3.3.3 Data Modelling

 Flowchart: A schematic or stepwise representation of an algorithm.

In conclusion, the Design methods that were used are as follows;

3.4.1 Rapid Application Development

Rapid Application Development (RAD) is a team-based technique that speeds up informa-

 JQuery. This framework is intended to reduce the cumbersomeness of writing plain

3.5 System Testing and Validation

3.5.1 Unit Testing

3.5.3 Usability Testing

System Study Analysis and Design

4.2 System Study

4.2.1 Strengths of Existing Systems

Below are the strengths of the existing systems:

 Real time tracking of projects is offered in some of the reviewed projects.

4.2.2 Weaknesses of Existing Systems

Below are the weaknesses of the existing systems:

4.3 System Analysis

4.3.1 Data Collection

Table 4.1: Respondents from interview sessions and questionnaires

4.3.2 Data Analysis

Analysis of Respondent’s Gender Against the Social Media Platforms

WhatsApp FaceBook Twitter Instagram SnapChat

Chatting Jobs Educational Purposes Blogging Others

Figure 4.3: Analysis of Respondents awareness (alumni) of Makerere University Projects

Figure 4.4: Analysis of Respondents awareness (students) of Makerere University Projects

Membership/ Alumni Groups

Flowchart: A schematic or stepwise representation of an algorithm.

JQuery. This framework is intended to reduce the cumbersomeness of writing plain

Real time tracking of projects is offered in some of the reviewed projects.

System Administrators: They have a higher understanding of how the system

The mentorship module should allow registered users to be mentored.

The financial module should be able to facilitate contributions to projects through

The system must provide logon security at the application level.

The system should be easy to maintain and adoptable to users.

All transactions must have audit trails.

Register create an account

Log onto the system

Interact and engage through forums, stories and messaging

View and contribute towards projects

Log onto the system

Manages security and backs up system data