A RESEARCH PROJECT SUPERVISION SYSTEM

By Richard Muhangi Reg. no: 2005/HD18/0031U BSc.Surveying (Mak), CCNA rmuhangi@gmail.com, 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

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

iii

Approval

This project report has been submitted for examination with the approval of the following supervisors.

Signed........................................ Dr. Joseph Ssewanyana

Date....................................

Department of Information Technology Faculty of Computing and Information Technology, Makerere University

Signed........................................ Mr. Joseph Semwogerere

Date....................................

Department of Information Technology Faculty of Computing and Information Technology, Makerere University

Signed........................................ Dr. Gilbert Maiga

Date....................................

Department of Information Technology Faculty of Computing and Information Technology, Makerere University

iv

Dedication

To my wife ANN, and children CHANTAL, RYAN and the yet to be born.

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.

vi

CONTENTS
List of Figures..x ABSTRACTxi 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 REVIEW6 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

vii

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

viii

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 WORK51 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

ix

List of Figures
4.1 5.1 5.2 5.3 5.4 5.5 5.6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 Data Flow at Faculty of Computing and Information Technology. ....17 Preliminary system model ...21 Combined ER Model ...27 Validated ER Model ....35 Design View of the Concept Paper Table in the DBMS .........36 Design View of the Supervisors Table ....37 Design View of the Project Report Progress Table .....37 Login dialog .....43 Student interface ..44 Upcoming and Missed meetings between Supervisor and Student .....45 The Student search sub-menu ..45 Comments stored and retrieved in the diary ........46 Progress bars showing days spent on each milestone...46 Supervisor credentials table .....47 Table for capturing topics for concept papers...47 Student credentials table in MS Access Database Management System .48 Table for setting up meetings ...49 Table for comments (Diary) by both Student and Supervisor ..49

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.

xi

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.

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.

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 Universitys Faculty of Computing and Information Technology.

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.

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.

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 supervisees own intellectual development. She refers to Barnard Goodyears (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 7

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 members 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

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

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 learners 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

10

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 customers 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

11

customers 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 systems 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, nonflexible 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). 12

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 Universitys ARIS, HURIS, and FINIS.

13

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.

14

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.

15

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.

16

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

17

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) (ii) (iii) (iv) (v) Allocate supervisors to students Get information about supervisors and their areas of specialization Monitor performance of the supervisors Monitor performance of the students Be accessible from anywhere

4.2.2 FUNCTIONAL REQUIREMENTS The system was required to: (vi) (vii) (viii) Maintain diaries for students and supervisors Allow research coordinator to add, edit and delete students and supervisors Allow research coordinator to assign permissions

4.2.3 NON FUNCTIONAL REQUIREMENTS The following are the non functional system requirements: (i) (ii) (iii) (iv) (v) The system must be secure Users should be involved at all stages The system should be completed within the allocated time for the project The design and implementation of the system shall aim to keep it simple Interface with existing systems like ARIS, HURIS and FINIS 18

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. ii. List research areas for a given supervisor List supervised project(s) for a given supervisor, showing the status (ongoing, completed, abandoned) iii. iv. v. vi. vii. viii. ix. x. xi. xii. xiii. xiv. Provide information on scheduled meetings between student and supervisor List dates that students will make their viva voce presentation Enable the research coordinator assign a supervisor to a student Enable a student read comments and remarks made by the supervisor and/or reviewer Enable research office staff record received documents Enable the supervisor set meeting dates Enable supervisor enter review details for student making a viva voce presentation Enable supervisor monitor students progress Enable student monitor his/her progress Enable research office monitor students progress Enable research coordinator recommend examiners Enable supervisor remark in the diary

19

xv. xvi. xvii.

Enable research coordinator assign a reviewer List reviewed project proposals for a given reviewer Capture contract details of a given student

xviii. List details of a project being done by a given student xix. xx. xxi. xxii. Enable student view dates for his project presentation Enable research coordinator arrange project presentations Enable supervisor get alerts for missed meetings Enable supervisor get reminders for impending meetings

xxiii. Enable student get alerts for missed meetings xxiv. Enable student get reminders for impending meetings

20

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 21

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.

22

Entity Types:

Research coordinator Student Supervisor ProjectPresentations Diary Logbook ProjectProposal ResearchAreas Reminders Projects

Concept Paper Examiner ProjectProgress Contract Reviewer VivaVoce Meetings ProjectReport Alerts

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

23

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

24

ENTITY RELATIONSHIP MODEL

alerts/ reminders +eventName : any(idl) +todayDate : double(idl) +eventDate : double(idl) * project +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)

Specialises in 1..*

researchArea +topic : any(idl)

Supervisor +SupervisorID : any(idl) +firstName : string(idl) +lastName : string(idl) +email : any(idl) -faculty : string(idl) -department : string(idl) -tel : long(idl) 1 1

receives 1 1 Assigned to 0..* Participates in 1 student -studentNo : double(idl) +firstName : string(idl) +lastName : string(idl) +email : any(idl) +course : any(idl) +plan : string(idl) -telNo : long(idl) +registrationNo : double(idl) 1

0..*

has 1 1 makes 1..*

1..* recorded in 1

arranges S-monitors 1..* meeting +studetNo : double(idl) +meetingDate : double +setupDate : double(idl)

projectPresentation a-makes +topic : any(idl) +StudentNumber : double(idl) +studentName : string(idl) 1..* to 1..* 1..* 1..* logbook +date : double(idl) +studentNo : double(idl) +topic : string(idl) +supId : double(idl) -recorder : string(idl)

- 1..* projectProgress projectprogress +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)

1..* vivaVoce +topic : any(idl) +date : double(idl) +examiner : string(idl) +approved : string(idl) -revisionNeeded : string(idl) -remarks : string(idl) -failed : string(idl)

1..*

1..*

reviewer +reviewerID : any(idl) +firstName : string(idl) +lastName : string(idl) +email : any(idl) -faculty : string(idl) -department : string(idl) -tel : long(idl)

recommends

examiner +examinerID : any(idl) +firstName : string(idl) +lastName : string(idl) +email : any(idl) -faculty : string(idl) -department : string(idl) -tel : long(idl)

Below is an Atomic Entity Relationship Model derived from the relationship statements above, indicating the multiplicities.

25

26

Figure 5.2: Combined ER Model

27

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)

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)

29

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 30

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*)

31

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)

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) 33

Supervisor-viva (studentNo*, topic, supId)

34

Figure 5.3: Validated ER Model (Red ink indicates the transaction requirements) 35 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.

Figure 5.5: Design View of the Supervisors Table

Figure 5.6: Design View of the Project Report Progress Table

37

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 38

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

ConceptPaper

Student

firstName lastName staffNo topic open approved startDate dateClosed abandoned firstName lastName studentName registrationNo telNo email course plan examinerID firstName lastName telNo email supId firstName lastName telNo email faculty department

Staff number

Student First L Last name Student registration number Telephone number Email address Project ( Plan B) only considered Examiners Identity number

Text Text Text Text Text Text Date/ Time Date/ Time Text Text Text Text Text Integer Text Text Text Text Text Text Integer Text Text Text Text Integer Text Text Text

No No No No No No No Yes No No No No No Yes No No No No No No Yes No No No No Yes No No No

Examiner

Supervisor

ProjectProgress

studentNo supId topic startDate dateClosed abandoned open approved topic studentNo studentName studentNo date supervisors[sup1, sup2, sup3] terms date supId studentNo remarks supId firstName lastName tel email faculty department date studentNo topic supId recorder topic examiner approved revisionNeeded remarks

Text Text Text Date/ Time Date/ Time Text Text Text Text Text Text Text Date/ Time Text Text Date/ Time Text Text Text Text Text Text Integer Text Text Text Date/ Time Text Text Text Text Text Text Text Text Text

No No No No Yes

No No No No No No No No No No No No No No No Yes No No No No No No No No No No

ProjectPresentations

Contract

Diary

Reviewer

Logbook

Person recording in logbook

VivaVoce

40

failed ProjectProposal studentNo topic supervisor supId startDate dateClosed abandoned open approved supId studentNo meetingDate setupDate topic studentNo supervisor supId topic startDate endDate prMilestone1 abandoned open approved supId studentNo eventName todayDate eventDate supId studentNo eventName todayDate eventDate

Text Text Text Text Text Date/ Time Date/ Time Text Text Text Text Text Date/ Time Date/ Time Text Text Text Text Text Date/ Time Date/ Time Text Text Text Text Text Text Text Date/ Time Date/ Time Text Text Text Date/ Time Date/ Time No No No No No Yes Yes Yes Yes No No No No No No No No No No Yes No Yes Yes Yes No No No No No No No No No No

Meetings

ResearchAreas ProjectReport

Project report milestone 1

Reminders

Alerts

Supervisor ID

41

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

42

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

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.

44

Supervisor profile after login:

Figure 6.3: Upcoming and Missed meetings between Supervisor and Student

Below, a deeper look at the supervisors 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.

45

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

46

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.

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.

48

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

49

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. ii. iii. iv. v. vi. vii. Requires authentication, thus applies basic security for the data in the system Assigns user profiles which Allows upload and download of documents The Diary function facilitates communication between student and supervisor The supporting database is scalable and allows interoperability The system is dynamic Java platform has a lot of inbuilt security, the prototype enjoys this

Weaknesses of the prototype: i. ii. iii. Several functions are not completed, though included on the interfaces System not web based (intranet based) 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.

50

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.

51

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.

52

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.

53

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. (7 ed) Oxford University Press. ISBN 0-19-

th

431661-0

23. Pressman, R. (2001). Software Engineering A practitioners 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. 54

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

55

APPENDICES

APPENDIX 1 SAMPLE CODE

APPENDIX 2 INTERVIEW QUESTIONS

APPENDIX 3 FEEDBACK ON SYSTEM TESTING

56

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)); 57

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) 58

.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); 59

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; 60

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 ( ) ; 61

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; } }

62

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() 63

{ 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; } }

64

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? 65

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

66

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.

67