A RESEARCH PROJECT SUPERVISION SYSTEM
By
Richard Muhangi Reg. no: 2005/HD18/0031U
BSc.Surveying (Mak), CCNA [email protected], tel: (+256) 0752 447344
A Project Report Submitted to School of Graduate Studies in Partial Fulfillment for the Award of
Master of Information Technology Degree of Makerere University
Option: Information Security
May, 2008
iii
Declaration
I, RICHARD MUHANGI do hereby declare that this project report is original and has not been
published and/or submitted for any other degree award to any other University before.
Signed .............................................. Date..........................................
Richard Muhangi
BSc. SURVEYING, CCNA
Department Of Information Technology
Faculty of Computing and Information Technology
iv
Approval
This project report has been submitted for examination with the approval of the following
supervisors.
Signed........................................ Date....................................
Dr. Joseph Ssewanyana
Department of Information Technology
Faculty of Computing and Information Technology, Makerere University
Signed........................................ Date....................................
Mr. Joseph Semwogerere
Department of Information Technology
Faculty of Computing and Information Technology, Makerere University
Signed........................................ Date....................................
Dr. Gilbert Maiga
Department of Information Technology
Faculty of Computing and Information Technology, Makerere University
v
Dedication
To my wife ANN, and children CHANTAL, RYAN and the yet to be born.
vi
Acknowledgement I am greatly indebted to a number of people who have in many ways, contributed to the success of
this study.
I thank my final team of supervisors; Dr. Ssewanyana, Mr. Semwogerere and Dr. Maiga, for
enabling my successful completion of the project. Thanks to Dr. Tom Wanyama for the expert
advice and guidance right from the conceptualization of the project, Mr. Drake Mirembe for helping
me model my project proposal for final approval, and Dr. F F. Tusubira for your wise counsel,
before I embarked on this project.
Mr. Joseph Nkangi encouraged me to take up this course and made me believe that I could make it
and look, I did. I thank the staff of Rural Electrification Agency for tolerating me when I had to
allocate time towards pursuit of this cause.
Special thanks go to my friends and classmates who have been supportive through out the course;
Gensi Michael, Nassiwa Annette, and Mr. Owora Henry.
Ronnie Muwanguzi, your contribution is invaluable. Only God can reward you.
God bless you all.
vii
CONTENTS
List of Figures……………………………………………………………………………………..x
ABSTRACT………………………………………………………………………………………xi
INTRODUCTION………………………………………………………………………………...2
1.1 BACKGROUND .................................................................................................................. 2
1.2 STATEMENT OF THE PROBLEM.................................................................................... 4
1.3 GENERAL OBJECTIVE ..................................................................................................... 4
1.3.1 SPECIFIC OBJECTIVES.............................................................................................. 4
1.4 SCOPE.................................................................................................................................. 4
1.5 JUSTIFICATION ................................................................................................................. 5
LITERATURE REVIEW…………………………………………………………………………6
2.1 RESEARCH PROJECTS ..................................................................................................... 6
2.2 RESEARCH PROJECT SUPERVISION............................................................................. 7
2.3 RESEARCH PROJECT SUPERVISION SYSTEM............................................................ 7
2.4 EXISTING SUPERVISION SYSTEMS.............................................................................. 7
2.4.1 MANUAL SYSTEMS ................................................................................................... 8
2.4.2 AUTOMATED TRACKING......................................................................................... 8
2.4.3 JUST-IN-TIME RESPONSES....................................................................................... 8
2.4.4 RESOLUTION TRACKING SYSTEM ........................................................................ 9
2.4.5 STUDENT TRACKING SYSTEMS........................................................................... 10
2.5 PROBLEMS WITH EXISTING SUPERVISION SYSTEMS .......................................... 12
2.6 CONCLUSION................................................................................................................... 13
viii
METHODOLOGY……………………………………………………………………………….14
3.1 OVERVIEW ....................................................................................................................... 14
3.2 LITERATURE REVIEW ................................................................................................... 14
3.3 REQUIREMENTS DETERMINATION ........................................................................... 15
3.3.1 SYSTEM STUDY ....................................................................................................... 15
3.3.2 INTERVIEWS ............................................................................................................. 15
3.4 DESIGN.............................................................................................................................. 15
3.5 IMPLEMENTATION......................................................................................................... 15
3.6 TESTING............................................................................................................................ 15
SYSTEM STUDY AND ANALYSIS…………………………………………………………...16
4.1 SYSTEM STUDY .............................................................................................................. 16
4.1.1 THE SYSTEM IN PLACE .......................................................................................... 16
4.1.2 DATA FLOW IN EXISTING SYSTEM..................................................................... 17
4.2 SYSTEM ANALYSIS........................................................................................................ 18
4.2.1 USER REQUIREMENTS ........................................................................................... 18
4.2.2 FUNCTIONAL REQUIREMENTS ............................................................................ 18
4.2.3 NON FUNCTIONAL REQUIREMENTS .................................................................. 18
4.2.4 CONFLICTING REQUIREMENTS ........................................................................... 19
4.2.5 TRANSACTION REQUIREMENTS ......................................................................... 19
DESIGN………………………………………………………………………………………….21
5.1 SYSTEM ARCHITECTURE ............................................................................................. 21
5.2 DATABASE DESIGN ....................................................................................................... 22
5.2.1 CONCEPTUAL DESIGN ........................................................................................... 22
5.4.2 LOGICAL DESIGN .................................................................................................... 28
ix
5.4.3 PHYSICAL DESIGN .................................................................................................. 36
SYSTEM IMPLEMENTATION AND RESULTS……………………………………………...43
6.1 SYSTEM IMPLEMENTATION........................................................................................ 43
6.1.1 GRAPHICAL USER INTERFACES .......................................................................... 43
6.2 TESTING AND RESULTS................................................................................................ 50
CONCLUSION, RECOMMENDATIONS AND FUTURE WORK……………………………51
7.1 SUMMARY AND CONCLUSION ................................................................................... 51
7.2 RECOMMENDATION...................................................................................................... 51
7.3 FUTURE WORK................................................................................................................ 51
REFERENCES…………………………………………………………………………………..52
APPENDICES…………………………………………………………………………………...56
APPENDIX 1 – SAMPLE CODE............................................................................................ 57
APPENDIX 2 – INTERVIEW QUESTIONS .......................................................................... 65
APPENDIX 3 – FEEDBACK ON SYSTEM TESTING ......................................................... 67
x
List of Figures 4.1 Data Flow at Faculty of Computing and Information Technology. ……….………..….17
5.1 Preliminary system model ………………………………………………………..…….21
5.2 Combined ER Model …………………………………………………….…….……….27
5.3 Validated ER Model ………………………………………………………...………….35
5.4 Design View of the Concept Paper Table in the DBMS ......………………………..….36
5.5 Design View of the Supervisors Table ……………………………………………...….37
5.6 Design View of the Project Report Progress Table …………..……………………..….37
6.1 Login dialog …………………………………………….……………………………....43
6.2 Student interface …………………………………………….………………………….44
6.3 Upcoming and Missed meetings between Supervisor and Student …..…….……….….45
6.4 The Student search sub-menu ……………………………………………………….….45
6.5 Comments stored and retrieved in the diary …………….………………………….......46
6.6 Progress bars showing days spent on each milestone………………………………...…46
6.7 Supervisor credentials table ……………………….……………………………….…...47
6.8 Table for capturing topics for concept papers…………………………………………...47
6.9 Student credentials table in MS Access Database Management System ……………….48
6.10 Table for setting up meetings …………………………………………………………...49
6.11 Table for comments (Diary) by both Student and Supervisor .………………………….49
xi
ABSTRACT
There are several cases of graduate students failing to complete their studies due to incomplete final
year research projects. This is largely related to the way supervision and tracking of students’
progress is handled. Although of recent, reforms have been introduced in the supervision of these
projects at the Faculty of Computing and Information Technology of Makerere University, the
researcher observed and studied literature on the workings of the existing student supervision
systems, identified loopholes within these systems, and established user and system requirements
which guided the design and development of this prototype. The implementation was based on an
application and database design, which was then tested for conformity to the objectives of the study.
Overall, the study achieved the objective of putting together a research project supervision system
that enhances communication and research progress tracking between the students, their supervisors
and research office by use of systematic recording, reminders, and proper document management.
2
Chapter 1
INTRODUCTION
1.1 BACKGROUND
Many graduate students take long to complete their studies at universities here in Uganda. Where
as they may complete their semester exams successfully, the research project component poses a
serious challenge to both the students and staff, leading to non completion of the degree
programs in several cases. As a result, there are cases of dissatisfaction on the part of students
who lose hope of ever completing there postgraduate programs within a set period of time. It is
noted also that some of these students have traveled out of the country and managed to start and
complete fresh postgraduate courses at other universities in the stipulated time.
According to Ochieng (2004), “none completion of a research is not a reflection of high
standards with in an institution, neither does it mean nothing has been achieved by the student. In
most cases, it is arising from the independent qualities of the supervisor and supervisee, and/ or
lack of harmonious interaction between the two”.
There was need to address some of the issues contributing towards this unfortunate trend. The
researcher embarked on a fact finding mission by accessing available literature on research
project supervision processes, observing the enterprise, interviews and interactions among
others. The findings and subsequent prototype development along with conclusions and
recommendations are discussed in the chapters that follow.
3
Definition of theoretical terms:
Research: a careful study of a subject, especially in order to discover new facts or information
about it, according to Oxford Advanced Learners Dictionary.
Project: piece of work involving careful study of a subject over a period of time, done by school
or college students, according to Oxford Advanced Learners Dictionary.
Supervision: is the act of watching over the work or tasks of another who may lack full
knowledge of the concept at hand. Supervision does not mean control of another but guidance in
a work, professional, or personal context, according to wikipedia.
System: According to Balmelli et al. (2006), “a system is a set of resources that is organized to
provide services.” The services enable the system to fulfill its role in collaboration with other
systems to meet some useful purpose. Systems may consist of combinations of hardware,
software (including firmware), workers, and data.
Research Project Supervision System: Derived from above, this is a set of resources organized
to watch over tasks involved in studies carried out by school or college students over a period of
time to discover new facts or develop solutions to existing problems.
4
1.2 STATEMENT OF THE PROBLEM
The main problem identified was poor communication and research progress tracking between
the students, their supervisors and research office.
1.3 GENERAL OBJECTIVE The general objective of this project was to develop a supervision system that enhances
communication between the students, their supervisors and research office.
1.3.1 SPECIFIC OBJECTIVES (i) To review the existing literature on research project supervision systems.
(ii) To determine requirements for developing a system that tracks progress of research projects.
(iii) To develop a prototype of a new research project supervision system.
(iv) To test this prototype against the requirements determined in (ii) above
1.4 SCOPE According to Oppaga (2006), these systems target Student profiles like registration, degree
requirements, critical course modules, topic tests, grade boundaries, mark books and reports. The
researcher focused on understanding how the existing systems of supervision work by
observation and reviewing literature on these systems, identification of system requirements
through interviews, and developing the supervision system prototype at Makerere University’s
Faculty of Computing and Information Technology.
5
1.5 JUSTIFICATION Smith (2005) explains that tracking student achievement would allow schools to improve
learning outcomes by specifically targeting areas/students that the data identifies. He adds that
schools are accountable for student achievements and need to find ways to measure this and to
act on the data collected on students’ progress. Smith maintains that schools need to help
teachers to learn how to use student assessment results to modify and target their own classroom
pedagogy.
This system provides a comprehensive set of record-keeping and reporting capabilities, from
tracking students’ infractions to gathering data on research patterns. The easy-to-use system not
only keeps data on issues related to the students progress, but can also integrate with other
information systems to track administrative issues like registration, fees payments and other
related information if the design is extended. It therefore allows academic institutions to
synchronize records.
6
Chapter 2
LITERATURE REVIEW
2.1 RESEARCH PROJECTS
The intent of the research model is to support proactive and interactive design process planning
and control, group decision making, value performance assessment and learning by project
stakeholders. Understanding project influences is necessary, and by utilizing design rationale
systems, greater insights can be made into the decision process as the project definition phase
develops (Ballard et al., 2000). They go ahead to establish a project definition module within the
lean project delivery system. "Project definition is the first phase in project delivery and consists
of three modules: Determining requirements (stakeholder needs and values), translating those
requirements into criteria for both product and process design, and generating design concepts
against which requirements and criteria can be tested and developed".
Ballard et al. (2000) therefore support collaborative design processes through the specification of
data collection methods and a project definition conference(s) to support group decision-making,
leading to the production and alignment of requirements, criteria and concepts.
Glisson and Chowdhury (2002) in their design of a digital dissertation information management
system aim at achieving three major functions; helping managers (dissertation coordinators,
support staff) in the management of past dissertations, helping supervisors and students perform
current dissertation-related activities online, and provision of online access to (search and
browse) the dissertations.
7
2.2 RESEARCH PROJECT SUPERVISION Ocheng (2004) defines supervision as a process by which a research student is guided and
enabled to acquire techniques and methods in research, without disrupting or misguiding the
supervisee’s own intellectual development. She refers to Barnard Goodyear’s (1998) definition
of supervision which states, “Supervision is an intervention that is provided by a senior member
of a profession, the supervisor, to a junior member or members of that profession (supervisee).”
She adds that none completion of a research is not a reflection of high standards within an
institution, neither does it mean nothing has been achieved by the student. In most cases, it is
arising from the independent qualities of the supervisor and the supervisee, and/or lack of
harmonious interaction between the two.
2.3 RESEARCH PROJECT SUPERVISION SYSTEM The existing supervision system at Faculty of Computing and Information Technology of
Makerere University is such that a student makes the required input, takes the document to
research office which in turn stamps and delivers it to the supervisor. This system depends on the
timely physical delivery of this document to the supervisor, which may suffer delays sometimes.
There is no log book for the student to sign against, just in case these documents get misplaced.
This system has loopholes like; delivery delays, receipt acknowledgement, and geographical
access limitation which would be addressed by developing a network-based automated system of
research project supervision.
2.4 EXISTING SUPERVISION SYSTEMS Oppaga (2006) explains that there exist student progress tracking systems in several Universities
around the world. However, these systems address general issues like; registration, degree
requirements, number of course hours, critical courses to remain on track, replacing counseling
8
manuals, improving data communication, encouraging early selection of majors, and specifying
grade points needed to maintain core subjects. According to Florida Virtual School (2006),
calculating progress reports for the students by the teachers requires the following criteria for
their Virtual School Administrator (VSA) performance-based system; i) Percent of course
completed, ii.) Pace of the student, and iii.) Contact with teacher maintained by student. The
majority of related literature is specifically on progress tracking systems, which are discussed in
the following sub sections:
2.4.1 MANUAL SYSTEMS
The existing supervision system at Makerere University is largely manual, and the short comings
of this have already been highlighted in sub section 2.3 above. It would not be easy if called
upon, for a supervisor to quickly and accurately report on the progress of all students they
supervise.
2.4.2 AUTOMATED TRACKING
According to Ong (2006), this is the ability to track emergence of issues such as a delayed
project, omission of project phases, lack of member’s participation, lack of or late submissions,
unsatisfactory planning of future tasks and incompleteness of planned tasks. Automated tracking
is executed by comparative analysis of syntactical representation in the submitted plan with the
predefined project template and past plans of the group.
2.4.3 JUST-IN-TIME RESPONSES
According to Micro search (2005), this is the ability to compose (with the aid of response
templates) responses for raised issues after the automated tracking. Compiled responses are
9
validated by tutors before being forwarded to students via e-mail and/or on the web page. This
should be:
(i) Personalized; Retrieval of information and varying level of permission based on the role
(Course Coordinator, Lecturer, Tutor, Student) of the user;
(ii) Flexible: Allow adaptation to projects beyond the software development domain, and of
varying magnitude.
2.4.4 RESOLUTION TRACKING SYSTEM
Usually, the process of tracking resolutions can be a resource draining process involving
excessive paper and correspondence that has no central control. But with a Resolution Tracking
System, it is easy to manage and monitor each resolution as it is submitted and its progress
through the approval process. The central hosting facility stores all resolutions submitted and
allows quick and easy access to all resolution related data at any time. Bradshaw (2003)
describes the database driven system that he developed to manage the resources used within the
Department of Computing and Information Technology at Peter Symonds College. The system
manages the entire range of learning material used within this Department and enables students
and staff to search course material, view material via the syllabus or via topic or categories. It
was developed to keep track of student progress on the course including topic test scores,
progress grades and homework updates. This system allows students to monitor their own
progress by way of a personal login-id and password on the Intranet. On the database the student
administration system is broken down into several areas; Student profile, Modules; Progress
Review, Topic Tests, Grade Boundaries, Mark Book and Reports. The student profile allows
staff to view individual student details such as group, coursework results, mocks and topic test
scores. For modules, views on grades for mock modules and examinations are given. The mark
10
book is a simple electronic homework mark book for staff to monitor the progress of their
students says Bradshaw (2003).
The researcher designed a prototype of an automated tracking system. Coordinator, supervisor
and student profiles were created in order to appropriate permissions for system use.
2.4.5 STUDENT TRACKING SYSTEMS
Student tracking systems enable increasing numbers of community colleges to respond to
external demands for accountability with tangible measurements of student progress and
institutional outcomes. Several recent trends have prompted interest in monitoring student
progress throughout college and into their professional lives. Bers (1989) argues that increasing
emphasis on marketing, accountability, communication with students, and internal competition
for students all serve as catalysts for the development of tracking systems while Helic et al.,
(2000), contends that a good online tutoring requires monitoring of a learner’s progress with the
material and testing of the acquired knowledge and skills on a regular basis. Educational research
shows that monitoring the students’ learning is an essential component of high quality education,
and is one of the major factors differentiating effective schools and teachers from ineffective
ones. It is evident in the works of Galusha (1997) that the use of tracking and progress systems
have significantly been applied to online teaching, assessment and measurement and has enabled
teachers to gauge the student response, feedback, and progress towards goals, and has been very
crucial in distance education. Ragan (1998) also recommends that the use of tracking systems
solves the problem where learners who are impaired by the lack of casual contact with the
teacher and other students are easily reached through the system. Pressman (2001), explains that
a critical part of project planning is to itemize the tasks, develop an initial schedule and assign
11
supervisors as needed to accomplish those tasks. As development progresses it is important to
monitor the completion of those tasks, to review the associated products and to determine if
changes, alternative plans, or re-assignment are required. Since the projects are team-oriented, it
is essential that a synergy develop among the supervisors and students to complete tasks and also
between the research office and the research panel for advice and insight into the research project
issues.
McConnell (1997) also believes that when working on a complex project, it is important for the
students, supervisors and faculty to track the research projects to confirm adherence to the
schedule and to detect problems early when there might be time to do something about them. If
the students and faculty do not track projects, they cannot control them. And, if a project is not
being controlled, it is out of control. Without tracking, students and supervisors have no way to
monitor potential problems or to know whether the project plans are being carried out correctly
or accurately. Douglas (1999) explains that the market changes that most firms are confronted
with today are becoming more global with greater and more diverse competition. Because of
this, a firm must quickly, efficiently and completely target its methods for meeting the
fundamental requirement for innovation. A tracking system is one such method that will ensure
that there is a systematic and robust approach to achieving a high level of incremental
innovation.
However in designing a tracking system, Fatemeh (1997) states that a major problem in dealing
with information-systems reliability is the design of a metric that combines the customer’s needs
and preferences with the technical specifications and modular reliability of information systems.
In order to develop a metric for a tracking system, there is need for a combination of the
12
customer’s requirements and utility with the technical structure of the system. The resulting goal
is a single metric that can be used for tracking the performance of an information system and as
an early signal of the system’s persistent malfunction and low quality of service. This metric can
also contribute to the continuous improvement of system reliability by identifying the
components whose improved reliability could make the most significant contribution to the
overall reliability of the system according to Fatemeh (1997).
2.5 PROBLEMS WITH EXISTING SUPERVISION SYSTEMS Amon (2000) explains that more recent research has begun to explore the notion of a supervisory
‘triangle’ which expands the dyadic model of supervision to include the client as a third member
of its’ functioning unit. He adds that supervision systems should exhibit “wholeness” in which
all parts are related, so that change in one part of the system will result in changes in all other
parts; and they should also exhibit “equifinality”; similar initial conditions can result in different
outcomes, and similar outcomes can yield from different initial conditions. Bohdanowicz et al.,
(2004) cites constraints in existing supervision systems to include; proprietary interfaces,
proprietary protocols, operating system dependent implementation, non-flexible architecture.
Sadovykh (2004) also argues that most of these supervision systems have several constraints
like; interoperability issues, component portability, development/deployment complexity, non-
flexible architecture, and dedication to a particular monitoring layer.
It was noted that in context of multiple migration and integration paths, many different problems
occur because the software architecture and structure of information systems have changed from
pure monolithic systems to a combination of different plat-forms such as standardized software,
component-based systems, web-based systems and especially portal systems (Martin and Bakhto,
2007).
13
2.6 CONCLUSION
From the literature review, it was clear that much as student tracking systems may exist at some
academic institutions, research project students were not catered for. Although the supervision
process at the Faculty of Computing and Information Technology has undergone several
transformations over the years, there still exists a need to automate the processes in order to
enjoy the benefits of a comprehensive research project supervision system. The desired model is
one whose design is platform independent and easily interoperable/integrated with other legacy
systems like Makerere University’s ARIS, HURIS, and FINIS.
14
Chapter 3
METHODOLOGY
3.1 OVERVIEW In this chapter, the basic methodology for the research project and the key elements of the
system design methods used are described. The main goal was to develop a research project
supervision system in order to improve the way research projects are handled at the Faculty of
Computing and Information Technology of Makerere University.
In the first section, an analysis of the literature on existing systems is performed with the aim of
identifying shortcomings in these systems with regard to research project supervision. The next
section addresses determination of system requirements, followed by design techniques
deployed, then the techniques used to implement the system, ending with the testing and
validation section.
3.2 LITERATURE REVIEW
To achieve objective (i) of reviewing existing supervision systems, Connolly and Begg (2005)
suggest examining documents, interviews, observing the enterprise in operation, research, and
questionnaire.
Examining documents and research were preferred for clarity and verification of facts to collect
information about existing systems and associated problems through avenues like journals,
reference books, and the Internet as good sources of information on approaches used elsewhere
to solve similar problems.
15
3.3 REQUIREMENTS DETERMINATION
3.3.1 SYSTEM STUDY To achieve objective (ii) of defining the requirements for designing the supervision system, a
system study and analysis for the organization was carried out. The system study and analysis are
discussed in detail in chapter four.
3.3.2 INTERVIEWS Interviews were carried out with a number of stakeholders who were categorized as; students,
supervisors or research coordinators. A copy of the interview questions is attached in appendix 2.
3.4 DESIGN
To achieve objective (iii) of designing the proposed system, the researcher designed the database
using conceptual, logical, and physical database design as recommended by Connolly and Begg
(2005).
3.5 IMPLEMENTATION
Rapid Application Development (RAD) technique was deployed using JAVA NETBEANS due
to the time constraint associated with the project. Java programming was used to execute the
provisions on the graphical user interface (GUI).
3.6 TESTING
To achieve objective (iv) of testing and validation, the researcher gave the prototype to
stakeholders at the Faculty of computing and Information Technology. The users’ views and
comments were then integrated in the final prototype.
16
Chapter 4
SYSTEM STUDY AND ANALYSIS
4.1 SYSTEM STUDY
4.1.1 THE SYSTEM IN PLACE
The researcher studied existing literature and observed the supervision process at Faculty of
Computing and Information technology of Makerere University in order to gain deep
understanding of the subject. Currently, final year students are required to come up with topics
for their research projects, which are developed further into concept papers, whose format is
provided by the research office.
Once a concept paper has been accepted by the research office, a supervisor conversant with the
research area is assigned to the student. The supervisor then guides the student to develop a
research or project proposal. Once a proposal has been presented to a panel of professors and
accepted, the student is given a go ahead to pursue the research study or project upon which the
student works closely with their supervisor until a final research/project presentation is made to
the satisfaction of the examination panel, and a final research/project report handed in to school
of graduate studies. Else, one of the reviewers is assigned to the student if there are minor
changes to make before proceeding. In case the proposal is rejected with major changes
expected, the student may have to start afresh, sometimes even change the research or project
topic. This flow of events is summarized in the section that follows.
17
4.1.2 DATA FLOW IN EXISTING SYSTEM
Below is a diagrammatic representation of the flow of data in the existing supervision system at
Faculty of Computing and Information Technology, Makerere University.
Figure 4.1: Data Flow in the supervision process at Faculty of Computing and Information Technology
18
As shown in figure 4.1 above, the main actors in the research/ project processes are students,
supervisors and research coordinator (in research office).
4.2 SYSTEM ANALYSIS 4.2.1 USER REQUIREMENTS The following user requirements were established from the interviews:
(i) Allocate supervisors to students
(ii) Get information about supervisors and their areas of specialization
(iii) Monitor performance of the supervisors
(iv) Monitor performance of the students
(v) Be accessible from anywhere
4.2.2 FUNCTIONAL REQUIREMENTS The system was required to:
(vi) Maintain diaries for students and supervisors
(vii) Allow research coordinator to add, edit and delete students and supervisors
(viii) Allow research coordinator to assign permissions
4.2.3 NON FUNCTIONAL REQUIREMENTS
The following are the non functional system requirements:
(i) The system must be secure
(ii) Users should be involved at all stages
(iii) The system should be completed within the allocated time for the project
(iv) The design and implementation of the system shall aim to “keep it simple”
(v) Interface with existing systems like ARIS, HURIS and FINIS
19
4.2.4 CONFLICTING REQUIREMENTS
(i) Interfacing with existing systems like ARIS, HURIS and FINIS may lead to delays in
project completion
(ii) Access from any where and the security requirement are in conflict as online access
exposes the system to attacks
4.2.5 TRANSACTION REQUIREMENTS The following were identified as the transaction requirements for the design of the database on
which the student supervision system would run.
i. List research areas for a given supervisor
ii. List supervised project(s) for a given supervisor, showing the status (ongoing, completed,
abandoned)
iii. Provide information on scheduled meetings between student and supervisor
iv. List dates that students will make their viva voce presentation
v. Enable the research coordinator assign a supervisor to a student
vi. Enable a student read comments and remarks made by the supervisor and/or reviewer
vii. Enable research office staff record received documents
viii. Enable the supervisor set meeting dates
ix. Enable supervisor enter review details for student making a viva voce presentation
x. Enable supervisor monitor students’ progress
xi. Enable student monitor his/her progress
xii. Enable research office monitor students’ progress
xiii. Enable research coordinator recommend examiners
xiv. Enable supervisor remark in the diary
20
xv. Enable research coordinator assign a reviewer
xvi. List reviewed project proposals for a given reviewer
xvii. Capture contract details of a given student
xviii. List details of a project being done by a given student
xix. Enable student view dates for his project presentation
xx. Enable research coordinator arrange project presentations
xxi. Enable supervisor get alerts for missed meetings
xxii. Enable supervisor get reminders for impending meetings
xxiii. Enable student get alerts for missed meetings
xxiv. Enable student get reminders for impending meetings
21
Chapter 5
DESIGN
5.1 SYSTEM ARCHITECTURE
Figure 5.1: Preliminary system model
Above is the overview of the proposed system. It shows the major components that facilitate the
functionality of the system, along with the interfaces. The student and supervisor’ computers
present a graphical user interface (GUI) that resides on the client end of the system, while the
administrator GUI presents both the client and server side access. The data server performs the
role of authentication and access control by storing user accounts and related profiles. The file
22
server performs the role of document or file storage. Such documents include concept papers,
research project proposals, diaries, log books, project reports, research dissertations, and any
other document involved in the supervision process.
5.2 DATABASE DESIGN According to Connolly and Begg (2005), design methodology consists of phases each containing
a number of steps, which guide the designer in the techniques appropriate at each stage of the
project. It helps the designer to plan, manage, control and evaluate database development
projects. They (Connolly and Begg) divide the methodology into three main phases: conceptual,
logical, and physical database design
5.2.1 CONCEPTUAL DESIGN
Connolly and Begg (2005) define conceptual design as the process of constructing a model of
data used in an enterprise, independent of all physical considerations. There are 9 steps involved
in the Conceptual design namely:
• Identify the Entity types
• Identify the Relationship types
• Identify and associate attributes with entity or relationship types
• Determine attribute domain
• Determine candidate, primary and alternate key attributes
• Consider use of enhanced modeling concepts (optional)
• Check model for redundancy
• Validate conceptual model against user transactions
• Review conceptual model with user.
23
Entity Types:
Research coordinator Concept Paper Student Examiner Supervisor ProjectProgress ProjectPresentations Contract Diary Reviewer Logbook VivaVoce ProjectProposal Meetings ResearchAreas ProjectReport Reminders Alerts Projects Relationship Statements: Research co-ordinator Assigns Supervisors Research co-ordinator Receives Project Research co-ordinator Monitors ProjectProgress Research co-ordinator Facilitates ProjectPresentations Student Makes ProjectPresentations Research co-ordinator Recommends Examiners Student Signs Contract Supervisor Remarks in Diary Student Reads Diary Supervisor Specialises in Research Areas
24
Supervisor Assigned to Students Project Recorded in Logbook Student Receives Reminders Supervisor Gets Reminders Student aReceives Alerts Supervisor aGets Alerts Supervisor Arranges Meetings Supervisor Participates in Viva Voce Student Presents Viva Voce Student Has Project Supervisor S-Monitors ProjectProgress Student Views ProjectProgress
--+topic : any(idl)+StudentNumber : double(idl)+studentName : string(idl)
projectPresentation
ENTITY RELATIONSHIP MODEL
-+SupervisorID : any(idl)+firstName : string(idl)+lastName : string(idl)+email : any(idl)-faculty : string(idl)-department : string(idl)-tel : long(idl)
Supervisor
1
1..*
-+topic : any(idl)+date : double(idl)+examiner : string(idl)+approved : string(idl)-revisionNeeded : string(idl)-remarks : string(idl)-failed : string(idl)
vivaVoce
---+topic : any(idl)+projectMilestone1 : any(idl)+projectMilestone2 : any(idl)+projectMilestone3 : any(idl)-projectStartDate : double(idl)-projectDeadline : double(idl)-abandoned : any(idl)-open : any(idl)-closed : any(idl)
project---studentNo : double(idl)+firstName : string(idl)+lastName : string(idl)+email : any(idl)+course : any(idl)+plan : string(idl)-telNo : long(idl)+registrationNo : double(idl)
student
1..*1..*
1
0..*
1
1..*
researchArea
-+date : double(idl)+studentNo : double(idl)+topic : string(idl)+supId : double(idl)-recorder : string(idl)
logbook
--+eventName : any(idl)+todayDate : double(idl)+eventDate : double(idl)-
alerts/ reminders
-----------+studentNo : any(idl)+supId : string(idl)+startDate : double(idl)+todayDate : double(idl)-deadline : double(idl)-expectedDuration : double(idl)-actualDuration : double(idl)-pms1 : string(idl)-pms2 : double(idl)-pms3 : double(idl)-pms1StartDate : double(idl)-pms2StartDate : double(idl)-pms3StartDate : double(idl)-pms1FinishDate : double(idl)-pms2FinishDate : double(idl)-pms3FinishDate : double(idl)
projectProgress
1
1..*
+studetNo : double(idl)+meetingDate : double+setupDate : double(idl)
meeting
Participates in
Assigned to
1
1..*
Specialisesin
1
1..*
S-monitors 1
1..*
makes
-+examinerID : any(idl)+firstName : string(idl)+lastName : string(idl)+email : any(idl)-faculty : string(idl)-department : string(idl)-tel : long(idl)
examiner
1..*
1..*
10..*
*
1
arranges1..*
1
recorded in
1 1..*
has
-+reviewerID : any(idl)+firstName : string(idl)+lastName : string(idl)+email : any(idl)-faculty : string(idl)-department : string(idl)-tel : long(idl)
reviewer *1
a-makes
to
receives
-+topic : any(idl)
recommends
projectprogress
25
Below is an Atomic Entity Relationship Model derived from the relationship statements above, indicating the multiplicities.
26
27Figure 5.2: Combined ER Model
5.4.2 LOGICAL DESIGN Connolly and Begg explain that “the main objective of logical database design is to translate the conceptual representation to the logical
structure of the database, which includes designing the relations”. The relations for the logical data model below were derived from the
conceptual data model created in the preceding section.
RELATIONAL MODEL
ResearchCordinator (firstName, lastName, staffNo) ConceptPaper (topic, open, approved, startDate, dateClosed, abandoned) Student (firstName, lastName, studentNo, registrationNo, telNo, email, course, plan) Examiner (examinerId,firstName, lastName, tel, email) Supervisor (supId, firstName, lastName, tel, email, faculty, department) ProjectProposal (supervisor, supId, topic, startDate, dateClosed, abandoned, open, approved) ProjectProgress (studentNo, supId, startDate, todayDate, deadline, expectedDuration, actualDuration, pms1, pms2, pms3, pms1StartDate, pms2StartDate, pms3StartDate, pms1FinishDate, pms2FinishDate, pms3FinishDate) CPProgress(studentNo, supId,cpStartDate, todayDate,cpDeadline, cpms1StartDate, cpms2StartDate, cpms3StartDate, cpms4StartDate, cpms1Deadline, cpms2Deadline, cpms3Deadline, cpms4Deadline, cpms1FinishDate, cpms2FinishDate, cpms3FinishDate, cpms4FinishDate, cpms1, cpms2, cpms3, cpms4) PPProgress(studentNo, supId,cpStartDate, todayDate,ppDeadline, ppms1StartDate, ppms2StartDate, ppms3StartDate, ppms1Deadline, ppms2Deadline, ppms3Deadline, ppms1FinishDate, ppms2FinishDate, ppms3FinishDate, ppms1, ppms2, ppms3)
29
PRProgress(studentNo, supId,cpStartDate, todayDate,cpDeadline, prms1StartDate, prms2StartDate, prms3StartDate, prms1Deadline, prms2Deadline, prms3Deadline, prms1FinishDate, prms2FinishDate, prms3FinishDate, prms1, prms2, prms3) Contract (date, supervisors[sup1,sup2,sup3], terms) Diary (remarks, date)
Reviewer (supId, firstName, lastName, tel, email, faculty, department)
Logbook (date, studentNo, topic, supId, recorder)
Viva (topic, date, examiner, approved, revisionNeeded, remarks, failed)
ProjectReport (supervisor, supId, topic, startDate, endDate, PRMilestone1, Abandoned, Open, Closed)
Meetings (studentNo, meetingDate, setupDate)
ResearchAreas (topic)
Reminders (eventName, todayDate, eventDate)
Alerts (eventName, todayDate, eventDate)
ProjectPresentations ( Topic, StudentNo, StudentName )
Projects (Topic, PMilestone1, PMilestone2, PMilestone3, PStartDate, PDeadline, Abandoned, Open, Closed)
30
MAPPING THE ER MODEL TO THE RELATIONAL MODEL
Step 1: Strong Entities
ResearchCordinator (staffNo, firstName, lastName)
Reviewer (supId, firstName, lastName, tel, email, faculty, department)
Step 2:Weak Entities
None Step 3: One to One Relationships
ProjectProgress (studentNo*, supId, startDate, todayDate, deadline, expectedDuration, actualDuration, pms1, pms2, pms3, pms1StartDate, pms2StartDate, pms3StartDate, pms1FinishDate, pms2FinishDate, pms3FinishDate) CPProgress(studentNo*, supId,cpStartDate, todayDate,cpDeadline, cpms1StartDate, cpms2StartDate, cpms3StartDate, cpms4StartDate, cpms1Deadline, cpms2Deadline, cpms3Deadline, cpms4Deadline, cpms1FinishDate, cpms2FinishDate, cpms3FinishDate, cpms4FinishDate, cpms1, cpms2, cpms3, cpms4) PPProgress(studentNo*, supId,cpStartDate, todayDate,ppDeadline, ppms1StartDate, ppms2StartDate, ppms3StartDate, ppms1Deadline, ppms2Deadline, ppms3Deadline, ppms1FinishDate, ppms2FinishDate, ppms3FinishDate, ppms1, ppms2, ppms3) PRProgress(studentNo*, supId,cpStartDate, todayDate,cpDeadline, prms1StartDate, prms2StartDate, prms3StartDate, prms1Deadline, prms2Deadline, prms3Deadline, prms1FinishDate, prms2FinishDate, prms3FinishDate, prms1, prms2, prms3) Diary (date, supId, studentNo *, remarks) Contract (StudentNo* , date, supervisors[sup1,sup2,sup3], terms) Step 4: One to Many Relationships
31
Supervisor (supId, firstName, lastName, tel, email, faculty, department, staffNo*, studentNo*)
Examiner (examinerId,firstName, lastName, tel, email, staffNo*)
Diary (date, supId*, studentNo , remarks)
Projects (StudentNo* , Topic, PMilestone1, PMilestone2, PMilestone3, PStartDate, PDeadline, Abandoned, Open, Closed) ProjectProposal (supervisor, supId, topic, startDate, dateClosed, abandoned, open, approved) ConceptPaper (topic, open, approved, startDate, dateClosed, abandoned) ProjectReport (supervisor, supId, topic, startDate, endDate, PRMilestone1, Abandoned, Open, Closed) Logbook (studentNo* , date , topic*, supId, recorder, staffNo) Meetings (supId*, studentNo, meetingDate, setupDate) Viva (studentNo*, topic, date, examiner, approved, revisionNeeded, remarks, failed)
ProjectPresentations (StudentNo*, Topic, StudentName, presentationDate, staffNo* )
Student (studentNo , firstName, lastName, registrationNo, telNo, email, course, plan,supId*)
ResearchAreas (topic, supId*)
Reminders (supId*, studentNo*, eventName, todayDate, eventDate)
Alerts (supId*, studentNo* , eventName, todayDate, eventDate) Step 5: Many to Many Relationships: Supervisor-viva (studentNo*, topic, supId)
FINAL RELATIONAL MODEL AFTER NORMALIZATION:
ResearchCordinator (staffNo, firstName, lastName)
Reviewer (supId, firstName, lastName)
StaffContacts (staffNo, tel, email)
Staff-Dept ( staffNo, dept)
Faculty (dept, faculty)
ProjectProgress (studentNo*, supId, startDate, todayDate, deadline, expectedDuration, actualDuration) ProjectMilestones (pms1, pms2, pms3)
ProjectMsStartDate (studentNo, pms1StartDate, pms2StartDate, pms3StartDate)
ProjectMsFinishDate (studentNo, pms1FinishDate, pms2FinishDate, pms3FinishDate)
CPProgress(studentNo*, supId,cpStartDate, todayDate,cpDeadline)
CPMilestones (cpms1, cpms2, cpms3, cpms4)
CPMSStartDates (studentNo, cpms1StartDate, cpms2StartDate, cpms3StartDate, cpms4Startdate) CPMSDeadlines (studentNo, cpms1Deadline, cpms2Deadline, cpms3Deadline, cpms4Deadline) CPMSFinishDates (studentNo, cpms1FinishDate, cpms2finishDate, cpms3FinishDate, cpms4FinishDate) PPProgress(studentNo*, supId,ppStartDate, todayDate,ppDeadline) PPMilestones (ppms1, ppms2, ppms3)
PPMSStartDates (studentNo, ppms1StartDate, ppms2StartDate, ppms3StartDate)
PPMSDeadlines (studentNo, ppms1Deadline, ppms2Deadline, ppms3Deadline)
33
PPMSFinishDates (studentNo, ppms1FinishDate, ppms2FinishDate, ppms3FinishDate)
PRProgress(studentNo*, supId, prStartDate, todayDate,prDeadline)
PRMilestones (prms1, prms2, prms3)
PRMSStartDates (studentNo, prms1StartDate, prms2StartDate, prms3StartDate)
PRMSDeadlines (studentNo, prms1Deadline, prms2Deadline, prms3Deadline)
PRMSFinishDate (studentNo, prms1FinishDate, prms2FinishDate, prms3FinishDate)
Contract (StudentNo* , date, supervisors[sup1,sup2,sup3], terms)
Student-Supervisor (studentNo,supId)
Supervisor (supId, firstName, lastName)
Examiner (examinerId,firstName, lastName)
Diary (date, supId*, studentNo , remarks)
Projects (StudentNo* , topic, Abandoned, Open, Closed)
ProjectProposal (StudentNo* , topic, supId, abandoned, open, approved)
ConceptPaper (StudentNo* , topic, open, approved, abandoned)
ProjectReport (StudentNo* , topic, supId, abandoned, open, closed)
Logbook (studentNo* , date , topic*, supId, recorder, staffNo)
Meetings (supId*, studentNo, meetingDate, setupDate)
Viva (studentNo*, topic, date, examiner, approved, revisionNeeded, remarks, failed)
ProjectPresentations (StudentNo*, Topic, StudentName, presentationDate, staffNo* )
Student (studentNo , firstName, lastName, registrationNo, courseCode, plan)
StudentContacts (studentNo, telNo, email)
Course (courseCode, courseName)
ResearchAreas (topic, supId*)
Reminders (supId*, studentNo*, eventName, todayDate, eventDate)
Alerts (supId*, studentNo* , eventName, todayDate, eventDate)
34
Supervisor-viva (studentNo*, topic, supId)
35
Figure 5.3: Validated ER Model (Red ink indicates the transaction requirements) See Sub subsection 4.2.4
5.4.3 PHYSICAL DESIGN This determines the physical implementation of the logical structure in a database management system
(DBMS). The DBMS used is Microsoft Access and below are screen shots of some of the tables:
Figure 5.4: Design View of the Concept Paper Table in the DBMS
As seen in figure 5.4 above, data types were determined to guide on the kind of valid entries that the
database can accept. The design also specifies which fields are required and which are optional, field
size (common for names and passwords), default value (see fig.5.5). These, among others provide for
integrity checking which is crucial for database security.
37
Figure 5.5: Design View of the Supervisors Table
Figure 5.6: Design View of the Project Report Progress Table
38
DATA DICTIONARY i) Entity relationship data dictionary
Entity Name Multiplicity Relationship Multiplicity Entity name
ResearchCoordinator
1:1 1:1 1:1 1:1
Assigns Receives Monitors Facilitates
0:* 0:* 1:* 0:*
Supervisor Project ProjectProgress ProjectPresentations
Supervisor
1:1 1:1 1:1 1:1 1:1 1:1 1:1 1:1
Remarks in Specialises in Assigned to Gets A-Gets Arranges Participates in S-Monitors
1:* 1:1 0:* 0:* 0:* 1:* 1:* 1:*
Diary ResearchArea Student Reminders Alerts Meetings VivaVoce ProjectProgress
Student
1:1 1:1 1:1 1:1 1:1 1:1 1:1 1:1
Makes Signs Reads Receives a-Receives Presents Has Views
1:* 1:1 1:1 0:* 0:* 1:* 1:* 1:1
ProjectPresentations Contract Diary Reminders Alerts VivaVoce Projects ProjectProgress
ii) Entity attribute data dictionary Entity Name Attributes Description Data Type & Length Nulls
Research coordinator firstName lastName staffNo
Staff number
Text Text Text
No No No
ConceptPaper topic open approved startDate dateClosed abandoned
Text Text Text Date/ Time Date/ Time Text
No No No No Yes No
Student firstName lastName studentName registrationNo telNo email course plan
Student First L Last name Student registration number Telephone number Email address Project ( Plan B) only considered
Text Text Text Text Integer Text Text Text
No No No No Yes No No No
Examiner examinerID firstName lastName telNo email
Examiner’s Identity number Text Text Text Integer Text
No No No Yes No
Supervisor supId firstName lastName telNo email faculty department
Text Text Text Integer Text Text Text
No No No Yes No No No
40
ProjectProgress studentNo supId topic startDate dateClosed abandoned open approved
Text Text Text Date/ Time Date/ Time Text Text Text
No No No No Yes No
ProjectPresentations topic studentNo studentName
Text Text Text
No No No
Contract studentNo date supervisors[sup1, sup2, sup3] terms
Text Date/ Time Text Text
No No No No
Diary date supId studentNo remarks
Date/ Time Text Text Text
No No No No
Reviewer supId firstName lastName tel email faculty department
Text Text Text Integer Text Text Text
No No No Yes No No No
Logbook date studentNo topic supId recorder
Person recording in logbook
Date/ Time Text Text Text Text
No No No No No
VivaVoce topic examiner approved revisionNeeded remarks
Text Text Text Text Text
No No
41
failed Text
ProjectProposal
studentNo topic supervisor supId startDate dateClosed abandoned open approved
Text Text Text Text Date/ Time Date/ Time Text Text Text
No No No No No Yes Yes Yes Yes
Meetings supId studentNo meetingDate setupDate
Text Text Date/ Time Date/ Time
No No No No
ResearchAreas topic Text No
ProjectReport studentNo supervisor supId topic startDate endDate prMilestone1 abandoned open approved
Project report milestone 1
Text Text Text Text Date/ Time Date/ Time Text Text Text Text
No No No No No Yes No Yes Yes Yes
Reminders supId studentNo eventName todayDate eventDate
Text Text Text Date/ Time Date/ Time
No No No No No
Alerts supId studentNo eventName todayDate eventDate
Supervisor ID Text Text Text Date/ Time Date/ Time
No No No No No
42
Projects
studentNo topic pMilestone1 pMilestone2 pMilestone3 pstartDate pDeadline abandoned open closed
Project Milestone 1 Project start date Project deadline
Text Text Text Text Text Date/ Time Date/ Time Text Text Text
No No No No No No No Yes Yes Yes
Chapter 6
SYSTEM IMPLEMENTATION AND RESULTS
6.1 SYSTEM IMPLEMENTATION The system was implemented using java net beans for interface design, backed up by java programming to operationalize these interfaces.
6.1.1 GRAPHICAL USER INTERFACES
Fig 6.1: Login dialog
The first interface that pops up when the application is started is the login dialog which requires
authentication of the system users. Categories of Coordinator, Supervisor, and Student have been
created to enforce profiles which implement the relevant permissions
44
Student profile after login:
Figure 6.2: Student interface When the student logs in, he is only able to view communication between the supervisor and themselves. He can also track his progress so far, respond to comments, and upload documents to their supervisor.
45
Supervisor profile after login:
Figure 6.3: Upcoming and Missed meetings between Supervisor and Student Below, a deeper look at the supervisor’s interface menu:
Figure 6.4: The Student search sub-menu The Supervisor is able to search students by the listed criteria in cases where the students assigned are many.
46
Below, the supervisor interface with the diary where he makes and views comments for his students
Figure 6.5: Comments stored and retrieved in the diary
Figure 6.6: Progress bars showing days spent on each milestone Colour code: Red - concept paper Green – Entire Project Cyan – Expected Duration of the Project Magenta – Time used up to-date
Colour code: Red - concept paper Green – Project proposal Cyan – Expected Duration of the Project Proposal Magenta – Time used up to-date
Figure 6.7: Supervisor credentials table
Figure 6.8: Table for capturing topics for concept papers
Figure 6.8 shows the table that stores data on concept papers submitted to Research Office, and the
status thereafter. The three possible states of the concept paper are; open (in progress), closed
(completed), and abandoned.
48
Figure 6.9: Student credentials table in MS Access Database Management System
When a user is created in the system, their details will be automatically stored in the relevant table
in the database. It is only the Research Coordinator who can add and remove users in the system.
Users can also be added directly into the database. However, they will not get their home directory
setup since this is only automated in the java application end.
49
Figure 6.10: Table for setting up meetings In figure 6.10 above, meeting appointments are entered into the table by the supervisor profile,
which become visible to the student as upcoming meetings. Once the date is passed, they are
removed from the “upcoming meetings” view to the “missed meetings” window as shown in figure
6.4.
Figure 6.11: Table for comments (Diary) by both Student and Supervisor
50
6.2 TESTING AND RESULTS The prototype was demonstrated and given to two supervisors, research office, and two students
for feed back on their interaction with the student supervision system. The following is the
summary of feed back from respondents.
Strengths of the prototype:
i. Requires authentication, thus applies basic security for the data in the system
ii. Assigns user profiles which
iii. Allows upload and download of documents
iv. The Diary function facilitates communication between student and supervisor
v. The supporting database is scalable and allows interoperability
vi. The system is dynamic
vii. Java platform has a lot of inbuilt security, the prototype enjoys this
Weaknesses of the prototype:
i. Several functions are not completed, though included on the interfaces
ii. System not web based (intranet based)
iii. Only basic administration tasks have been incorporated
Overall, it was found to satisfy its objective. The issues raised were incorporated in the final
version of the prototype where possible while others were left to be addressed in future work.
51
Chapter 7
CONCLUSION, RECOMMENDATIONS AND FUTURE WORK
7.1 SUMMARY AND CONCLUSION
In this study, the researcher evaluated existing progress measurement and supervision systems and
analyzed the weaknesses that exist in these systems. Requirements for the proposed system were
defined which guided the design, implementation and testing of the research project supervision
system. Overall, the researcher achieved the objective of putting together a research project
supervision system that enhances communication between the students, their supervisors and
research office.
7.2 RECOMMENDATION
Improvements have been incorporated and processes automated to improve research progress. This
tool should be adopted by the Faculty of Computing and Information Technology, and improved
further to enhance student research project supervision process. It may be rolled out to other
faculties and institutions of higher learning by customizing it to their scenarios.
7.3 FUTURE WORK I concentrated on students of plan B, which at Makerere University means students that opt for a
final year project whose duration is one semester. Future work should cater for Plan A students of
research where the duration is two semesters have a few deviations from Plan B, and can easily be
assimilated in this system. Future work should also address interfacing with the existing systems at
Makerere University like ARIS, HURIS and FINIS, as well as on-line access.
52
REFERENCES
1. Amon, L.K. (2000). The Application of Counseling Theory to Clinical Supervision:
Enhancing the Effectiveness of Supervision.
2. Ballard, G. and Zabelle, T. (2000). Project Definition, White Paper #9, Lean Construction
Institute, USA. Retrieved February 29, 2008, from http://www.leanconstruction.org
3. Balmelli, L., Brown, D., Cantor, M. and Mott, M. (2006). Model-driven systems
development. IBM Systems Journal, 45(3), 569- 585.
4. Bers, T. H (1989). Tracking Systems and Student Flow. Wiley Periodicals, 66, 3 – 7.
5. Bohdanowicz, J.E., Chliaev, P., Volochinov, V. and Sadvykh, A. (2004).
GeneSyS Project: Supervision of Distributed Systems (03E-SIW-043). Retrieved February
29, 2008, from http://genesys.sztaki.hu/downloads/03E-SIW-043.pdf
6. Bradshaw, G. (2003). Creation, Development and Use of a Database-driven Management
Tracking System
7. Charles, P. Pfleeger and S. L. Pfleeger (1997). Security in Computing. Prentice Hall.
8. Chirico, M., Giudici, F., Sappia, A. and Scapolla, A.M. (1997). The Real Experiment
eXecution Approach to Networking Courseware.
53
9. Douglas, K.H. (1999). Tracking systems as a catalyst for incremental innovation. MCB
University Press, 37(10): 786-791.
10. Fatemeh, M.Z. (1997). Reliability metric for information systems based on customer
requirements. International Journal of Quality and Reliability Management, 14(8): 791 -
813.
11. FLVS (2006). Keeping track of your students. Retrieved August 12, 2006, from
http://www.flvs.net/educators/keepingtrackstudents.php
12. Galusha, J. M. (1997). Barriers to learning in distance education. Retrieved September 11,
2006, from http://www.infrastruction.com/barriers.htm
13. Helic, D., Maurer, H. and Scherbakov, N. (2000). On Web Based Training: What do we
expect from the system. In Proceedings of the ICCE 2000 - 8th International Conference
on Computers in Education, National Tsing Hua University, Taiwan November 10-14,
2000, pp. 1689-1694.
14. Laprie, J. (1995). Dependability: Basic Concepts and Terminology.
15. Mahil, C. and Verner, J. (1995). Prototyping and Software Development Approaches
16. Martin, T. and Bakhto, A. (2007). System Supervision. Physical Security.
54
17. Mary, O. T. K. (2004). Graduate Studies Supervision at Makerere University: A book of
readings: Makerere University Press.
18. McConnell, S. (1997). Tool Support for Project Tracking. IEEE Software, 15(5): 119-120.
19. Microsearch (2005). Student Tracking System. Retrieved June 3, 2006 from
www.microsearch.net
20. Ong, N.S and Foo, W.C (2004). A Real-time work flow tracking system for a
manufacturing environment. Emerald Group Publishing Ltd 53(1): 33 - 43.
21. Oppaga. (2006). Student Tracking Systems Can be Used to Enhance Graduation and
Retention Rates. Retrieved 24th June, 2006, from
http://www.oppaga.state.fl.us/reports/pdf/0648rpt.pdf
22. Oxford Advanced Learners Dictionary. (7th ed) Oxford University Press. ISBN 0-19-431661-0
23. Pressman, R. (2001). Software Engineering A practitioner’s approach. (5th ed.) Berkeley:
McGraw-Hill.
24. Ragan, L. C. (1998). Good teaching is good teaching: An emerging set of guiding
principles and practices for the design and development of distance education.
DEOSNEWS, The American Center for the Study of Distance Education. Pennsylvania
State University, 8(12).
25. Sadovykh, A. (2004). Innovative Concept of Generic System Supervision.
55
26. Smith, D.H. and Weston, L. (2005). Tracking students’ progress through their R-7 journey
using a school based digital data collection system.
27. Thomas Connolly and Carolyn Begg (2005). Database Systems: A practical approach to
design,implementation, and management. (4th ed) Addison Wesley.
28. Wikipedia (2006). System. Retrieved June 1, 2006, from http://en.wikipedia.org/wiki.
29. William Bradley Glisson and Gobinda G. Chowdhrry (2002). Design of a digital
dissertation information management system. MCB UP Limited, 36[3]: 152-165
56
APPENDICES
APPENDIX 1 – SAMPLE CODE APPENDIX 2 – INTERVIEW QUESTIONS APPENDIX 3 – FEEDBACK ON SYSTEM TESTING
57
APPENDIX 1 – SAMPLE CODE CODE FOR LOGIN GRAPHICAL INTERFACE /* * LoginGui.java * * Created on December 30, 2007, 12:24 PM */ /** * * @author Muhangi Richard */ import javax.swing.JOptionPane; import java.util.ArrayList; public class LoginGui extends javax.swing.JFrame { String username; String password; String id,firstName,lastName,category; ArrayList userDetails; /** Creates new form Login */ public LoginGui() { initComponents(); } /** This method is called from within the constructor to * initialize the form. * WARNING: Do NOT modify this code. The content of this method is * always regenerated by the Form Editor. */ // <editor-fold defaultstate="collapsed" desc=" Generated Code "> private void initComponents() { jLabel1 = new javax.swing.JLabel(); jLabel2 = new javax.swing.JLabel(); jLabel3 = new javax.swing.JLabel(); jPFPassword = new javax.swing.JPasswordField(); jBtnLogin = new javax.swing.JButton(); jTFUsername = new javax.swing.JTextField(); setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE); setTitle("Student Supervision System: Login"); setResizable(false); jLabel1.setFont(new java.awt.Font("Tahoma", 1, 18)); jLabel1.setForeground(new java.awt.Color(204, 51, 0));
58
jLabel1.setText("Student Supervision System"); jLabel2.setText("Username"); jLabel3.setText("Password"); jBtnLogin.setText("Login"); jBtnLogin.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jBtnLoginActionPerformed(evt); } }); org.jdesktop.layout.GroupLayout layout = new org.jdesktop.layout.GroupLayout(getContentPane()); getContentPane().setLayout(layout); layout.setHorizontalGroup( layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING) .add(org.jdesktop.layout.GroupLayout.TRAILING, layout.createSequentialGroup() .add(57, 57, 57) .add(layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING) .add(layout.createSequentialGroup() .add(layout.createParallelGroup(org.jdesktop.layout.GroupLayout.TRAILING) .add(jLabel3) .add(jLabel2)) .add(22, 22, 22) .add(layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING) .add(jPFPassword, org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, 134, Short.MAX_VALUE) .add(jTFUsername, org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, 134, Short.MAX_VALUE))) .add(layout.createSequentialGroup() .add(91, 91, 91) .add(jBtnLogin) .addPreferredGap(org.jdesktop.layout.LayoutStyle.RELATED))) .add(61, 61, 61)) .add(org.jdesktop.layout.GroupLayout.TRAILING, layout.createSequentialGroup() .addContainerGap(39, Short.MAX_VALUE) .add(jLabel1) .add(32, 32, 32)) ); layout.setVerticalGroup( layout.createParallelGroup(org.jdesktop.layout.GroupLayout.LEADING) .add(layout.createSequentialGroup() .addContainerGap() .add(jLabel1) .add(23, 23, 23) .add(layout.createParallelGroup(org.jdesktop.layout.GroupLayout.BASELINE) .add(jLabel2)
59
.add(jTFUsername, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE, org.jdesktop.layout.GroupLayout.DEFAULT_SIZE, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE)) .add(19, 19, 19) .add(layout.createParallelGroup(org.jdesktop.layout.GroupLayout.BASELINE) .add(jLabel3) .add(jPFPassword, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE, 19, org.jdesktop.layout.GroupLayout.PREFERRED_SIZE)) .addPreferredGap(org.jdesktop.layout.LayoutStyle.RELATED, 28, Short.MAX_VALUE) .add(jBtnLogin) .addContainerGap()) ); pack(); }// </editor-fold> private void jBtnLoginActionPerformed(java.awt.event.ActionEvent evt) { // TODO add your handling code here: username = jTFUsername.getText(); password = jPFPassword.getText(); System.out.println("Username is "+username+"and password is "+password); int flag; if(username.equals("")) { JOptionPane.showMessageDialog(null, "Please Enter a Username"); jTFUsername.requestFocus(); } else { LoginDatabaseConnection login = new LoginDatabaseConnection(username,password); login.loadDriver(); login.makeConnection(); login.buildStatement(); login.executeQuery(); flag=login.checkLogin(); if(flag==1) { //JOptionPane.showMessageDialog(null, "Login Successful"); userDetails = login.getUserDetails(); firstName = (String)userDetails.get(0); lastName = (String)userDetails.get(1); category = (String)userDetails.get(2); id = (String)userDetails.get(3); String name = firstName+" "+lastName; if(category.equals("supervisor")) { SupervisorGui sup = new SupervisorGui(name,id); //sup.setUserDetails(name,id);S sup.setVisible(true);
60
this.dispose(); } else if(category.equals("student")) { JOptionPane.showMessageDialog(null, "Category is student"); } else if(category.equals("ResearchCordinator")) { JOptionPane.showMessageDialog(null, "category is research coordinator"); } //this.dispose(); //JOptionPane.showMessageDialog(null, "Welcome "+name); } else if(flag==0) { JOptionPane.showMessageDialog(null, "Login Failed Please try again"); jTFUsername.setText(""); jPFPassword.setText(""); jTFUsername.requestFocus(); } else if(flag==3) { JOptionPane.showMessageDialog(null, "User doesn't exist"); } else if(flag==2) { JOptionPane.showMessageDialog(null, "Please enter a password"); } } } /** * @param args the command line arguments */ public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { new LoginGui().setVisible(true); } }); } // Variables declaration - do not modify private javax.swing.JButton jBtnLogin; private javax.swing.JLabel jLabel1; private javax.swing.JLabel jLabel2; private javax.swing.JLabel jLabel3; private javax.swing.JPasswordField jPFPassword;
61
private javax.swing.JTextField jTFUsername; // End of variables declaration } CODE FOR PROCESSING PROJECT PROGRESS import java.sql.ResultSet; import java.sql.ResultSetMetaData; import java.sql.SQLException; import java.util.Date; import java.util.GregorianCalendar; import java.util.ArrayList; import javax.swing.JOptionPane; public class ProcessProjectProgress { ResultSet rs; int interval, interval1, interval2, interval3, flag=0; Date startDate=null ; Date deadline =null ; Date todayDate=null; Date cpDeadline=null; Date ppDeadline=null; GregorianCalendar calendar = new GregorianCalendar(); ArrayList intervals = new ArrayList(); public ProcessProjectProgress(ArrayList resultSet) { for(int i=0;i<resultSet.size();i++) { rs = (ResultSet)resultSet.get(i); if(rs!=null) { //JOptionPane.showMessageDialog(null, "Login Failed Please try again"); //System.out.println("TATATA"); } getProjectResults(); } } public void getProjectResults () { try { ResultSetMetaData metadata = rs . getMetaData ( ) ; int numberOfColumns = metadata . getColumnCount ( ) ;
62
System.out.println("PAPAPA "+numberOfColumns); while (rs . next ( ) ) { //System.out.println("MAMAMA"); startDate = rs . getDate ( "startDate") ; deadline = rs.getDate("deadline"); cpDeadline = rs.getDate("pms1Deadline"); ppDeadline = rs.getDate("pms2Deadline"); } todayDate = calendar.getTime(); interval = (int)((deadline.getTime() - startDate.getTime())/86400000); interval1 = (int)((todayDate.getTime() - startDate.getTime())/86400000); interval2 = (int)((cpDeadline.getTime() - startDate.getTime())/86400000); interval3 = (int)((ppDeadline.getTime() - startDate.getTime())/86400000); intervals.add(interval2); intervals.add(interval3); intervals.add(interval); intervals.add(interval1); //System.out.println("TATATA") } catch ( SQLException sqlException) { } } public ArrayList getIntervals() { return intervals; } public int getInterval1() { return interval1; } public int getInterval2() { return interval2; } }
63
CODE FOR PROCESSING MEETINGS /* * ProcessMeetings.java * * Created on 07 January 2008, 15:02 * * To change this template, choose Tools | Template Manager * and open the template in the editor. */ /** * * @author Richard Muhangi */ import java.sql.ResultSet; import java.sql.ResultSetMetaData; import java.sql.SQLException; import java.util.Date; import java.util.GregorianCalendar; import java.util.ArrayList; public class ProcessMeetings { ResultSet rs; ArrayList missedDate = new ArrayList(); ArrayList pendingDate = new ArrayList(); ArrayList missedStudent = new ArrayList(); ArrayList pendingStudent = new ArrayList(); ArrayList all = new ArrayList(); ArrayList missedStudentName = new ArrayList(); ArrayList pendingStudentName = new ArrayList(); Date meetingDate = null; Date todayDate = null; String studentNo,firstName,lastName, name; GregorianCalendar calendar = new GregorianCalendar(); public ProcessMeetings(ArrayList resultSet) { for(int i=0;i<resultSet.size();i++) { rs = (ResultSet)resultSet.get(i); if(rs!=null) { } getMeetingResults(); } } public void getMeetingResults()
64
{ try { ResultSetMetaData metadata = rs . getMetaData ( ) ; int numberOfColumns = metadata . getColumnCount ( ) ; while (rs . next ( ) ) { studentNo = rs.getString("studentNo"); meetingDate = rs.getDate("meetingDate"); firstName = rs.getString("firstName"); lastName = rs.getString("lastName"); name = firstName+" "+lastName; todayDate = calendar.getTime(); if(meetingDate.before(todayDate)) { missedDate.add(meetingDate); missedStudent.add(studentNo); missedStudentName.add(name); } else { pendingDate.add(meetingDate); pendingStudent.add(studentNo); pendingStudentName.add(name); } } all.add(missedDate); all.add(missedStudent); all.add(missedStudentName); all.add(pendingDate); all.add(pendingStudent); all.add(pendingStudentName); } catch ( SQLException sqlException) { } } public ArrayList getAll() { return all; } }
65
APPENDIX 2 – INTERVIEW QUESTIONS
Qn1. How is supervision of final year research projects handled at your University?
Qn2. What is the role of research office in supervision of students?
Qn3. What are the specific roles expected to be played by the supervisor(s) and the student(s)?
Qn4. Which indices are considered or do you suggest be used in measuring and tracking students’
progress?
Qn5. What is the recommended frequency of meetings between the student and their supervisor? Qn6. Is there an automated system in use for monitoring progress of research project supervision?
Qn7. Were you interviewed or consulted for your input towards requirements for the design of this
system?
Qn8. What are the strong points of current system of research project supervision?
Qn9. What are the weaknesses?
Qn10. In light of the above mentioned concerns, which recommendations can you make to the
researcher and what would be your expectations in this new system?
66
Qn11. Is there any other information you can give to assist the interviewer in establishing how the
current state of supervision and progress tracking can be further improved?
THANK YOU
67
APPENDIX 3 – FEEDBACK ON SYSTEM TESTING Qn1. What would you point out as the strong points of this prototype?
Qn2. Which are the weak points?
Qn3. Are you happy with the interface design?
Qn4. What do you think was left out as far as the main aim of the project is concerned?
Qn5. What do you recommend to be i) added in the prototype?
ii) removed from the prototype?
Thank you.
