FACULTY OF COMPUTING, INFORMATION SYSTEMS AND

MATHEMATICS DEPARTMENT OF INFORMATION TECHNOLOGY

PRACTICAL TRAINING REPORT ON SYSTEM DEVELOPMENT AND PC MAINTAINANCE

CONDUCTED AT CATHOLIC UNIVERSITY OF HEALTH AND ALLIED SCIENCES

CUHAS

P.O BOX 1464 MWANZA, TELL: 2500881, Email: vc@bugando.ac.tz

PREPARED BY:
NAME: MAKUNGU NGAMBA,
REG#: BIT/12/71954,
PROGRAM: BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY YEAR 3,
DURATION: SEVEN WEEKS.
SUPERVISOR: DANIEL KOLOSENI

DECLERATION
I, MAKUNGU NGAMBA the student of THE INSTITUTE OF FINANCE MANAGEMENT
(IFM) with registration number BIT/12/71954, I declare that this field report work I prepare on
my own with the assistance of different references and my field supervisor, and I identify all
work done and lessons learnt during my field attachment.

Signature: ............................................
Date: ...

FINAL REPORT OF FIELD PRACTICAL TRAINING

BY

MAKUNGU NGAMBA

ii

This Final Report is submitted to the Department of Information Technology, Faculty of

Computing, Information Systems and Mathematics, The Institute of Finance Management in
partial fulfillment of the requirements for

BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY
FACULTY OF COMPUTING, INFORMATION SYSTEMS AND MATHEMATICS
INSTITUTE OF FINANCE MANAGEMENT
2014

iii

ACKNOWLEDDGEMENT
A large number of people have contributed over several months to this practical work training
and Id like to thank everyone (IFM, CUHAS, reviewers, students) who have help to come up
with this report. Different constructive suggestions for change as well as many corrections to this
report.
I would particularly like to thank all Departments of Catholic University of Health and Allied
Sciences (CUHAS) for their acceptance, help and support during/after the training which lead me
to achieve more knowledge in system developments and maintenance, some of them are
ISMAEL KHANGANE, Venance Luhemeja, Adeline Urassa, Derick K, and others),
I would particularly like to thank all the IFM Department for their cooperation on my learning as
well as supervisors.
Also I would like to give thanks for the followings students for their contributions during/after
the practical training: David Y, Anna P and Humbo T (3rd year at IFM students), Simon R (3rd
year at UDOM), Jackline P (2nd year at MZUMBE) and other students from different
institutes/universities.
My God bless you all for your cooperation and contribution.

iv

Table of contents
DECLERATION............................................................................................................................................ i
ACKNOWLEDDGEMENT ........................................................................................................................ iv
EXECUTIVE SUMMARY ........................................................................................................................ vii
CHAPTER ONE ......................................................................................................................................... 1
INTRODUCTION....................................................................................................................................... 1
1.0.

OVERVIEW OF THE FIELD WORK PLACEMENT ...................................................... 1

1.1.

HISTORICAL REVIEW OF CUHAS .................................................................................. 1

1.2.

FUNCTIONS OF CUHAS...................................................................................................... 2

1.3.

CUHAS ORGANIZATION STRUCTURE .......................................................................... 3

1.4.

MAJOR SERVICES OF CUHAS ......................................................................................... 3

1.5.

ROLES OF CUHAS ON ITS BUSINESS ............................................................................. 4

CHAPTER TWO ........................................................................................................................................ 5

WORK DONE AND LESSON LEARNED .......................................................................................... 5
2.0.

DESCRIPTION OF WORK DONE AND LESSON LEANT ............................................. 5

2.1. COMPUTER MOUSE REPAIR AND MAINTENANCE ....................................................... 5

2.3. INSTALLATION OF WINDOWS 7. ............................................................................................ 6
2.4. DESIGNING A CALCULATOR ............................................................................................... 6
2.5. MEASURING OF HEARTBEAT .............................................................................................. 8
2.6. COLLECTION OF SYSTEM REQUIREMENTS ................................................................... 9
2.7. FUNCTIONAL REQUIREMENTS ..................................................................................... 10
2.8. SYSTEM ANALYSIS AND REQUIREMENT MODELING ............................................... 10
2.8.1. USE CASE DIAGRAM. ..................................................................................................... 12
2.8.2. SEQUENCE DIAGRAMS ................................................................................................. 12
2.8.3. STATE CHART DIAGRAM ............................................................................................. 13
2.9. SYSTEM FUNCTIONALITIES ........................................................................................... 14
2.10. SYSTEM DESIGN ............................................................................................................... 15
2.10.4. DESIGN THE LOGIN FORM PAGE. ........................................................................... 16
2.11. DATABASE DESIGN.......................................................................................................... 17
2.11.1. INTRODUCTION TO DATABASE AND STRUCTURED QUERY LANGUAGE
(SQL) .............................................................................................................................................. 17
2.11.2.

RELATIONAL DATABASE DEVELOPMENT. ...................................................... 18

2.11.3. DATA NORMALIZATION ............................................................................................. 18

v

2.11.4. DATA MODELING AND ER-MODELING.................................................................. 19

2.11.5. DATA INTEGRITY IN DATABASE ............................................................................. 19
2.17. E-LEARNING .......................................................................................................................... 20
CHAPTER THREE .................................................................................................................................. 21
LITERATURE REVIEW .................................................................................................................... 21
3.0. INTRODUCTION TO LITERATURE REVIEW ON REQUIREMENTS
ENGINEERING ................................................................................................................................ 21
3.1.

FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS .................................... 21

3.2.

REQUIREMENTS SPECIFICATION ............................................................................... 23

3.3.

REQUIREMENTS ELICITATION AND ANALYSIS ..................................................... 23

3.4.

REQUIREMENTS VALIDATION ..................................................................................... 24

3.5.

THE CONCLUSION OF LITERATURE REVIEW ......................................................... 25

CHAPTER FOUR..................................................................................................................................... 26
ANALYSIS OF STUDY ....................................................................................................................... 26
4.0.

INTRODUCTION TO ANALYSIS ..................................................................................... 26

4.1.

RELATIONSHIP BETWEEN CLASS KNOWLEDGE AND IN MARKET ................. 26

4.2.

SKILLS LEARNT DURING PRACTICAL TRAINING ................................................. 26

4.3.

SKILLS LACKING .............................................................................................................. 27

4.4.

EXPERIENCE GAINED AND CAREER PLAN .............................................................. 27

CHAPTER FIVE ........................................................................................................................................ 28

CONCLUSION AND RECOMMANDATION ..................................................................................... 28
5.0.

INTRODUCTION................................................................................................................. 28

5.1.

CONCLUSION...................................................................................................................... 28

5.2.

RECOMMENDATION .......................................................................................................... 29

Recommendation to CUHAS ....................................................................................................... 29

Recommendation to the IFM ....................................................................................................... 29
REFERENCES .......................................................................................................................................... 30

List of Figures
Figure 1 Organization structure of CUHAS (source: CUHAS).............................................................. 3
Figure 3 Use Case (Source: Project Team) ............................................................................................. 12
Figure 4 Sequence diagram (Source: Project Team) ............................................................................. 13
Figure 5 State Chart Diagram (Source: Project Team) ........................................................................ 13
vi

EXECUTIVE SUMMARY
The report describes a report of the field attachment training that was carried out in the period
between 08th July 2014 to 29th August 2014 at Catholic University of Health and Allied Science
(CUHAS). The training ran for seven (7) weeks of which I learnt various aspects on Information
and Communication Technology (ICT) involved the Department of Directorate of Information
System (DIS) and the Department of Decision Support System (DSS) working basically on
System Development and PC Maintenance.
The tasks undertaken during field training work was typically based on project of developing a
Hostel Reservation System. This was involved on Designing the graphic User Interface (GUI),
designing Database and the System Maintenance.
The followings are the task undertaken and their lessons leant during field practical training.
These work done are computer repair and maintenance, PC troubleshooting, windows
installation, calculator design, measuring of heartbeat, system topology, project management,
system cost estimation, system quality management, system analysis and requirement model,
UML diagram, defining system functionality, defining system menus, design of home page,
forms design, database design and data normalization, data modeling, E-learning, system testing
and application software.

vii

CHAPTER ONE
INTRODUCTION
1.0.OVERVIEW OF THE FIELD WORK PLACEMENT
The field practical training was conducted at Catholic University of Health and Allied Sciences
(CUHAS), located at the Bugando Medical Centre, Bugando Hill Nyamagana Mwanza Tanzania.
This field practical training took the time from 08th July 2014 to 29th August 2014. The field
practical training took seven (7). The following are the objectives of field work placement:
Opportunity for practical experience in the organization and to increase their knowledge and skill
in areas consistent with career goals.
a) To enable students to understand and appreciate professional duties and responsibilities
and personnel in the field. To help students determine their professional strength and
weakness.
b) To further enhance a students understanding and conceptualization of professionalism.
Help students use professional terminologies and respectful communication when
interacting with professionals and clients in the practice settings.
c) To assist the Institution from which the student is from with; A perspective for evaluating
student performance and improving curriculum.

1.1.

HISTORICAL REVIEW OF CUHAS

CUHAS-Bugando, as a Constituent University College of SAUT, became operational in

September 2003. It was granted a Certificate of Interim Authority (CIA) on the 28th March 2002
and a Certificate of Provisional Registration (CPR) on 27th March 2003. By 2005 the College was
firmly established and given full registration status by the Tanzania Commission of Universities
(TCU). The Commission was approved a request from SAUT to transform the College to a fullgrown university and granted CUHAS-Bugando a Certificate of Full Registration.
At its inception it was envisaged that it would be organized in faculties, institutes and directorates.
In 2009/2010 it decided to go into a school mode and therefore established four schools: The Weill
Bugando School of Medicine (which replaces the Faculty of Medicine), A School of Pharmacy,
the Archbishop Anthony Mayala School of Nursing, and a School of Public Health. The new

Schools had their first intake in the Academic Year 2010/2011.The Institute of Allied Health
Sciences was established within the Bugando University of Health Sciences in 2006/2007.
Contribution of the CUHAS Tanzanian organizations. The unique contribution of the partnership
is that we promote interdisciplinary education and research by working across schools
CUHASs contributes the followings
Generates over 50% of Tanzanias health professionals (doctors, graduate nurses, pharmacists and
dentists). Conducts most of the health research in the country. Now, champion in addressing the
gained its charter as a University in 2007 and requested to quadruple its graduate output.

1.2.

FUNCTIONS OF CUHAS

The main function of Catholic University of Health and Allied Sciences (CUHAS) is Teaching
Research & Consultancy Services. This make CUHAS to become an outstanding Tanzanian
Catholic University excelling in health care, training and research and responsive to societal needs.
Other functions are to provide skilled and competent human resources in the health sector that is
vested with moral and ethical values, Search, discover and communicate the truth to advance the
frontiers of knowledge and provide quality services to the community. Role of universities in
addressing the health workforce shortage to generate sufficient health professionals who are
competent to address the health needs of their society through:
a) Service to their communities
b) Provision of leadership in their professions
c) Supportive supervision and mentorship
d) Teaching the next generation
e) Research to improve health outcomes

1.3.

CUHAS ORGANIZATION STRUCTURE

Figure 1 Organization structure of CUHAS (source: CUHAS)

1.4.

MAJOR SERVICES OF CUHAS

The business of the University are the advancement of knowledge, diffusion and extension of
technology and learning, the provision of higher education and research and, so far as is consistent
with those objects, the nurturing of the intellectual, aesthetic, social and moral growth of the
students at the University. It has been set up:
a) To provide higher education in the area of Public Health through teaching and research to
persons suitably qualified and capable of benefiting from such education;
3

b) To disseminate knowledge and the results of research and their applications to the needs
and aspirations of the people of Tanzania.
c) To provide services to those contributing positively to improving the health status and
overall quality of the life of Tanzanians and foster partnership with the community.

1.5.

ROLES OF CUHAS ON ITS BUSINESS

The core roles of the Catholic University of Health and Allied Sciences (CUHAS) comprises the
following:
a) Work with integrity and maintain an empowering environment based on mutual trust,
respect and partnership among academic and non-academic staff, students and external
units.
b) Apply innovative educational approaches and technologies (including distance learning) to
enhance access to programs with a focus to train high caliber health professionals at all
levels of education.
c) Use modern information and communications technology and other educational tools to
drive its programs wherever possible.
d) Seek through research and service to be relevant to the health needs of Tanzania and
beyond; with future programs relating to emerging challenges and trends in both the health
and education sectors.
e) Be practically oriented by emphasizing community work as a compulsory component of
all programs offered in the School.
f) Develop curriculum that entails effective balance between academic knowledge and
competencies required in the world of work.
g) Collaborate with the Ministries of Health and Education, Ministries, Departments and
Agencies, professional bodies, the private sector and international institutions in the
attainment of the mission of the University.

CHAPTER TWO
WORK DONE AND LESSON LEARNED
2.0.DESCRIPTION OF WORK DONE AND LESSON LEANT
This section describes brief tasks undertaken and lessons leant during field work practical. The
followings are the task undertaken and their lessons leant during field practical training. These
work done are computer repair and maintenance, PC troubleshooting, windows installation,
calculator design, measuring of heartbeat, system topology, project management, system cost
estimation, system quality management, system analysis and requirement model, UML diagram,
defining system functionality, defining system menus, design of home page, forms design,
database design and data normalization, data modeling, E-learning, system testing and application
software. The following are the description of tasks taken and their leant lessons.

2.1. COMPUTER MOUSE REPAIR AND MAINTENANCE

The laptop mouse was not responding to the applied action, then I solved by checking the touchpad
settings by visiting the Start menu or the Windows search charm and type mouse settings. Then
select Change mouse settings. Once in the dialog box, I click the tab that seems to be for the
touchpad. This I make sure that everything is enabled. If there are setting buttons, make I sure that
everything is on. This method did not helpful, and decided to install a new driver by visiting laptop
manufacturer's web site and search for your model number and the words touchpad driver. Finally
the problem I solved
LESSON LEANT
It is important to make computer device repairing and maintenance in order to make PC function
well. Also fixing problems on your own PC will save you money for buying a new device.
Computer repair services also use many software diagnostic tools to determine what might be
wrong with a computer but most of the very best ones they use are available for free online. The
cleaning of hardware and update the software and ensure a better computer performance.

2.3. INSTALLATION OF WINDOWS 7.

During windows installation, I followed the all steps of windows 7 installation. Such steps are:
a) Inserting of bootable CD- ROM containing windows 7,
b) Entering the computer's BIOS,
c) Setting the BIOS's boot options menu,
d) Selecting the CD-ROM drive as the first boot device of the computer, then
e) Save the changes of the settings. Press the button indicated on the screen or select the
save option from the BIOS menu to save the configuration. Shutting off the computer.
Either turn off the computer by choosing the shut-down option in the current operating
system, or hold the power button until the computer powers off.
f) Starting the computer from the disc then I Choose the Windows Setup options then
clicked next.
g) Then, clicking the Install Now button to accept the License Terms.
h) Then decided on which hard drive and partition I want to install Windows 7 on. A hard
drive is a physical part of the computer that stores data, and partitions "divide" hard
drives into separate parts.
i) Install Windows 7 on the preferred hard drive and partition. Once you've decided on
where to install Windows 7, I select it and click next. Windows 7 begin installing up to
the end of installation.
LESSON LEANT
During windows installation you must understands all the required steps failure to this may cause
windows installation errors or windows problems may arise after installation. PC must be installed
the new OS so that to keep them function well. Linux OS is over power than windows, it can delete
the file of windows that is why used to delete the old windows after installation above. To make
more PC function efficiently drivers also must be installed.

2.4. DESIGNING A CALCULATOR

The following are the steps I taken during designing and improvement of calculator software device. I
opened Visual Basic 10 software and create a new Standard EXE Project. Standard EXE projects which

give the handful of commands and tools, useful to develop simple as well as semi-complex
6

programs. This needs to understand the project screen box with a lot of dots. This is the form where
you will add the various elements (command buttons, pictures, text boxes, etc.) of the program.
Dragged a label onto the form, and change the caption of the label to "Enter first number". The
caption of a label can be changed using the properties box.
Created a textbox to the right of the first label, and removed any text that appears inside the textbox
by changing blanking the "Text" field in properties box.
I created another label and change the caption to "Enter second number" and create another textbox
to its right and drag and create four command buttons below these two labels. Change the caption
of these command buttons to "Add", "Subtract", "Multiply", "Divide" respectively.
Create another label with a caption "Result" and a textbox to the right of it below the four command
buttons. This textbox will be used to display the result. With this, your design is complete.
To start coding, in the project explorer, I click on the form and then select the left-most button. It
will take you to the coding screen. By clicking on the list box in the top-left of the coding screen.
One by one, click on all the commands (Command1, Command2, etc.) so that the outline coding
of them will be visible to the coding screen.
I declared the variables. To declare: Dim a, b, r as Integer, a is the value entered in the first
textbox, b is the value entered in the second textbox and r is the result. Start the coding for the add
command (Command1). The code will be as follows:
Private Sub Command1_Click()
a = Val(Text1.Text)
b = Val(Text2.Text)
r=a+b
Text3.Text = r
End Sub
Code for the subtract command (Command2). The code will be as follows:
Private Sub Command2_Click()
a = Val(Text1.Text)
b = Val(Text2.Text)
r=a-b
7

Text3.Text = r
End Sub
Code for the multiply command (Command3). The code will be as follows:
Private Sub Command3_Click()
a = Val(Text1.Text)
b = Val(Text2.Text)
r=a*b
Text3.Text = r
End Sub
Code for the divide command (Command4). The coding will be as follows:
Private Sub Command4_Click()
a = Val(Text1.Text)
b = Val(Text2.Text)
r=a/b
Text3.Text = r
End Sub
Then clicked the start button or press F5 to execute the program. Finally saved project and the
form.

LESSON LEANT
All designing and coding procedures must be taken so that to avoid error during program
execution. Visual Basic 10 is a programming language developed by Microsoft which can be easily
learned and used by beginner, as well as advanced programmers.

2.5. MEASURING OF HEARTBEAT

The following instruments were used to create a topology of the heartbeat measuring equipment.
Components of this topology were Amplifier for amplifying the heartbeat sound. Microphone was
there for taking/absorbing the heartbeat and send them to the PC. Headphone was there for giving
8

out sound beat of the amplified heartbeat so that someone can hear such beats. The PC was for
connection of all other components and manage them to work.
LESSON LEANT
The heartbeat of human being can be measured by many connecting devices. A computer can
measure human heartbeat when connected with Amplifier, Microphone and Headphone. Amplifier
can amplifies to the biggest beat from smallest on. The topology diagram is more important
because it show the whole map of the system and their functions.
2.6. COLLECTION OF SYSTEM REQUIREMENTS
As a project team members we visited the hostel area and stockholder to collect system
requirements. This requirements complies both functional and non-functional requirement, user
requirement as well as system requirement in general. We discuss with the students and
stockholder who want and are the user of this required system by using questionnaire methodology
as a technique of collecting information. We structure some of the questions as follows: What are
the problems consign with booking hostel manually? How time did take on competing with hostel
room booking take? How difficulty arise on locating students to respective room? Why they want
to have a system.
The following technologies have being given high priority in this project for development of web
based driven Application. The application will have the client-server fetchers where the program
will be executed at the server (server side application) but it will be serving all the client/users for
their computers as long as they must be in the same Local Area network (LAN).
Software needed was:a) Wamp Server that will be used in the systems database development.
b) Macromedia Dream weaver CS6
c) PHP 5 that will be used to provide a link between the database and the web server.
d) Firefox, Torch, Internet explorer and Google chrome as browsing software.
It sets out the systems functions, services and operational constraints in details. The system was
required to be able to do the following; allow the student to submit personal information and to be
stored in a database, Storing information to the database, System provides feedback report of
9

booking student, student check for room availability before booking process and Staff/system
administrator login/logout, the student also was required to pay through M-pesa.

2.7. FUNCTIONAL REQUIREMENTS

During requirement collection our system was intended to accomplish and these are; system should
allow authorized system administrator/staff to login and logout of the system, System should
automate the student booking on Hostel room, System should provide report for student booking
process, Allow the student to check availability of room booking in hostel, System should allow
system administrator/staff to access different information of students details.

LESSON LEANT
Requirements collection or discovery also called requirements elicitation deals with gathering
information about the required system and existing systems, and distilling the user and system
requirements from this information. Sources of information during the requirements discovery
phase include documentation, system stakeholders, and specifications of similar systems other
come from the application domain and from other systems that interact with the system being
specified. Requirement gathering interact with stakeholders through interviews and observation
and you may use scenarios and prototypes to help stakeholders understand what the system will
be like. All of these must be considered during the requirements elicitation process.

2.8. SYSTEM ANALYSIS AND REQUIREMENT MODELING

At the beginning of a project of Hostel management system the analysis of system taken to ensure
that we collecting high-level requirements and to understand the full and planned scope of the
release Hostel system. For our initial requirements model was looking the followings:
Usage model. We think how users will work with the system. This may be a collection of essential
use cases on a Unified Process (UP) project, which language does user will use when interacting
with system, how the system user interface graphic will appear. The followings are some discussed
of judging parts of the system with users:

10

Student inputs her name and student registration number. System verifies the student is eligible to
room booking. If not eligible then the student is informed and use case ends. System displays list
of available hostel rooms. Student chooses a room. System validates the student is eligible to
booking in the chosen room. If not eligible, the student is asked to choose another. System validates
the room fits into the student's schedule. System calculates and displays the total costs and other
informations. Student verifies the cost and either indicates she wants to book or not. The system
prints booking receipt.
Domain model. A domain model identifies fundamental entity types and the relationships between
then. This we done using Class Responsibility Collaborator (CRC) cards and UML class diagram.
This domain model was comprised of enough information: the main domain entities, their major
attributes, and the relationships between these entities.
User interface model. Many proposed interfaces was suggested by team project members by
consider developing some screen sketches and even a user interface prototype.

LESSON LEANT
System analysis is responsible for making the system architecture explicit at an early stage in the
system development which requires some analysis. Architectural design results have a reflective
effect on whether or not the system can meet critical requirements such as performance, reliability,
and maintainability.
A requirements model meets two main needs which are Confirms what users want a new system
to do, must be understandable for users, must be correct and complete. Specifies what designers
must design which not unambiguous. The requirement model also do the followings: describes
what the system should do, represents people, things and concepts important to understand what
is going on, shows connections and interactions among these people, things and concepts, shows
the business situation in enough detail to evaluate possible designs and is organized so as to be
useful for designing the system.

11

2.8.1. USE CASE DIAGRAM.

The following use-case diagram shows how the hostel management system expected to be
interacted with users/students.

Figure 2 Use Case (Source: Project Team)

2.8.2. SEQUENCE DIAGRAMS

The sequence diagram below shows how the user/student and admin interact with the system and
show the flow of data expected.

12

Figure 3 Sequence diagram (Source: Project Team)

2.8.3. STATE CHART DIAGRAM

Figure 4 State Chart Diagram (Source: Project Team)

LESSON LEANT
System modeling using the UML, which include the following types of diagrams use case
diagrams, class diagrams, sequence diagrams, and state diagrams for modeling a the system. This
system modeling include graphical system models presenting the relationships between the system
13

components, the system, and its environment. The set of models describes the behavior of the
system and is explained with additional information describing, for example, the systems required
performance or reliability. The UML has many diagram types and so supports the creation of many
different types of system model. The UML suppose five diagram types could represent the
essentials of a system:
a) Activity diagrams, show the activities involved in a process or in data processing.
b) Use case diagrams, show the interactions between a system and its environment.
c) Sequence diagrams, show interactions between actors and the system and between system
components.
d) Class diagrams, show the object classes in the system and the associations between these
classes.
e) State diagrams, show how the system reacts to internal and external events.

2.9. SYSTEM FUNCTIONALITIES

The following were the hostel management system functionalities suggested by stockholder and
students at CUHAS. To support in improving the transparency of availability of services at various
student regardless their origin through online application. To introduce the room ordering system
between student and hostels. To increase access to a range of affordable booking services for all.
It intending to provide services of booking widely and easily for student demand.
To automate each and every activity of the manual system, which increases its throughput, to
provide a quick response with very accurate information as and when required, to make the present
manual system more interactive, speedy and user friendly, to avail any information, whatever and
whenever needed, reduce the cost of maintenance.

LESSON LEANT
The functionality of any system must provide components that implement system security, patient
information creation and updating, import and export of patient data from other databases, and
report generators that create management reports. Also system functions includes form and menu
management components that present information to users, and data validation components that
check information consistency.
14

Other system functionalities automate each and every activity of the manual system, which
increases its throughput, to provide a quick response with very accurate information as and when
required, to make the present manual system more interactive, speedy and user friendly, to benefit
any information, whatever and whenever needed, reduce the cost of maintenance.

2.10. SYSTEM DESIGN

The designing of hostel management system was started when some of requirement obtained
during collection the effective system requirements which was assisting us to reach our goals. This
we involved the use the iterative life cycle model for designing due to time limit. Requirements
collection and design was parallel and if any changes have to be made we considered. The
following were the design which involved during this process.
LESSON LEANT
This process overlaps significantly with the requirements development process. It involves
establishing the overall architecture of the system, identifying the different system components
and understanding the relationships between them.
The errors that designers make during system design are often a consequence of system design
decisions that lead to mistaken ways of working, or of organizational factors, which affect the
system operators.

2.10.1. HOME PAGE DESIGN

During design the home page, there was different prototypes designed by team members which
was submitted to the CUHAS stockholders for making choice which one was more attractable than
other home page. The following is an interface suggested by this stockholders.
LESSON LEANT
The homepage may introduce the company at system website when visitors visit, provide them
with clear paths to other pages on the site and also give them a strong sense. Creating a unique
design, having an interesting logo or otherwise memorable look for the homepage is important in
retaining the visitors and encouraging them to return to the site in the future.

15

It is advised to follow the principles of design and to be simple by provide plenty of visibility
colors and font size which will make visitors attraction, easy, clearly, navigations to the site.

2.10.2. MENUS DESIGN AND SUGGESTION

During system designing menus we considered some of assumptions of menu developing and
selections. We decided to put a horizontal navigation menus which was not very complicated so
that to avoid user conflict on using the system. Also we decided to presents few menus which make
the system simpler to use. Such menus are presented on the image bellow:
LESSON LEANT
A clean menu of a web design has the advantage of making simple and functional which means
that it make user to navigate successful from one page to another.
Easy navigation around a website is of the up-most importance when it comes to designing a
website. Here are some tips for website navigation. If the viewers are unable to use it and navigate
around it to find all of the important information they are searching for. Navigation is best
understood as the method in which you explore and move around the website.

2.10.3. DESIGNING REGISTRATION FORM

During system design we was able to suggest how the registration will occurs and how many
attributes should be filled during booking process. The booking for rooms we suggested to put
small number of requirements to be given by student. This was to reduce some errors during
booking time and to reduce time consuming when student book for room. The figure bellow show
the hostel booking form was.
2.10.4. DESIGN THE LOGIN FORM PAGE.
In order for a system users to be simple to proceed with booking a student was asked to create a
booking profile which was including the creation of login password and confirm them. This profile
a student was asked to use e-mail and his password to login the system. The figure bellow show
the hostel login form was.
LESSON LEANT
16

A web form is one of the best ways to get input from prospective clients and indirectly establish a
friendly relation with them. This form must be validated so that to control and checks for user
input. Validation of user input is analyzing the correctness of the user input. Not validating input
is one of the greatest mistakes that Web-application developers can make. This can lead to system
crashes, malicious database manipulation, and even database corruption.

2.11. DATABASE DESIGN

The database designing we practiced include the following touched parts. This we done in at least
knowing their definition.
2.11.1. INTRODUCTION TO DATABASE AND STRUCTURED QUERY LANGUAGE
(SQL)
SQL statements are divided into two major categories: data definition language (DDL) and data
manipulation language (DML). We discovered on Data Definition Language (DDL) and Data
Manipulation Language (DML). The DDL is about creation of database table and insertion of data
into the table. While DML, it just retrieves data rather than modifying it.
Looking on creating tables, I invested more on what required to create table of data. We discovered
some of attributes require to create table. Such as primary key and foreign key as well as data type.
When deciding to put data into a table I used the INSERT INTO statement. Its syntax is SQL
INSERT INTO Table name. We also discovered on how to retrieve data from the table by using
the syntax of the SQL SELECT Statement.
LESSON LEANT
a) Data Definition Language (DDL) statements are used to define the database structure or
schema. Some examples: CREATE, ALTER, DROP/DELETE, TRUNCATE, COMMENT
and RENAME.
b) Data Manipulation Language (DML) statements are used for managing data within schema
objects. Some examples: SELECT, INSERT, UPDATE, DELETE, MERGE, CALL,
EXPLAIN PLAN and LOCK TABLE.

17

2.11.2. RELATIONAL DATABASE DEVELOPMENT.

This I discovered that when creating a relational database, I defined the domain of possible values
in a data column and further constraints that may apply to that data value. For example, a domain
of possible students could allow up to ten possible student names but be constrained in one table
to allowing only three of these customer names to be specifiable. Each table record (or row)
contains a unique data instance defined for a corresponding column category. One or more data or
record characteristics relate to one or many records to form functional dependencies. These are
classified as follows: One to One, One to Many, Many to One: Many to Many.
LESSON LEANT
Relational Database performs "select", "project" and "join" database operations, where select is
used for data retrieval, project identifies data attributes, and join combines relations.
Relational Database have many other advantages, including:
a)

Easy extendibility, as new data may be added without modifying existing records. This is
also known as scalability.

b)

New technology performance, power and flexibility with multiple data requirement
capabilities.

c)

Data security, which is critical when data sharing is based on privacy.

2.11.3. DATA NORMALIZATION

During studying and practicing the data normalization, we recalled the Relational Model which
consists of the elements: relations, which are made up of attributes. From our discussion of E-R
Modeling, by taking entity type which was corresponding to a relation and that the Entitys
attributes become attributes of the relation. We also discussed how, depending on the relationships
between entities, copies of attributes were placed in related relations as foreign keys. During
normalization discussion we discovered also a Functional Dependency describes a relationship
between attributes within a single relation.

18

LESSON LEANT
The goal of data normalization is to reduce and even eliminate data redundancy, an important
consideration for application developers because it is incredibly difficult to stores objects in a
relational database that maintains the same information in several places. The three most common
forms of normalization ( First normal form (1NF), Second normal form (2NF), and Third normal
form (3NF)) describing how to put entity types into a series of increasing levels of normalization.

2.11.4. DATA MODELING AND ER-MODELING

By recalling the idea of designing a database structure that defines how stored information can be
accessed, categorized and manipulated. Its the very foundation of a database design effort, and
the specific data model employed drives the database diagram and overall development endeavors.
I learn why modeling is an engineering imperative as well as some of the more popular data model
techniques.
LESSON LEANT
a) Fundamentally a database should be easy to use and must maintain the integrity of the data
in a secure fashion.
b) A strong database model will also enable various ways to manage, control, and organize
the stored information to effectively execute multiple key tasks.
c) Database diagrams will provide needed documentation of the data links that facilitate
database functionality.
d) A good implementation of database to be, the data must be well logically designed in ERdiagram and data model.
2.11.5. DATA INTEGRITY IN DATABASE
The following are involved in data integrity which are referential integrity, entity integrity and
domain integrity. Two important steps in planning tables I discovered to identify valid values for
a column and to decide how to enforce the integrity of the data in the column.

19

LESSON LEANT
Data integrity falls into these categories:
a) Entity integrity defines a row as a unique entity for a particular table. Entity integrity
enforces the integrity of the identifier column(s) or the primary key of a table (through
indexes, UNIQUE constraints, PRIMARY KEY constraints, or IDENTITY properties).
b) Domain integrity is the validity of entries for a given column. You can enforce domain
integrity by restricting the type (through data types), the format (through CHECK
constraints and rules), or the range of possible values (through FOREIGN KEY constraints,
CHECK constraints, DEFAULT definitions, NOT NULL definitions, and rules).
c) Referential integrity preserves the defined relationships between tables when records are
entered or deleted. Referential integrity is based on relationships between foreign keys and
primary keys or between foreign keys and unique keys (through FOREIGN KEY and
CHECK constraints). Referential integrity ensures that key values are consistent across
tables. Such consistency requires that there be no references to nonexistent values and that
if a key value changes, all references to it change consistently throughout the database.

2.17. E-LEARNING
This was the presentation which was presented to us by the CUHAS IT Department. It was containing the
following parts: Asynchronous e-Learning, Self-paced Courses, Discussion Groups, Synchronous eLearning, Virtual Classroom, Audio and Video Conferencing, Chat, Shared Whiteboard, Application
Sharing, Instant Messaging, Development and Management, Learning Management Systems, Learning
Content Management Systems, Knowledge Management.

LESSON LEANT
E-Learning is the use of technology to enable people to learn anytime and anywhere. E-Learning can
include training, the delivery of just-in-time information and guidance from experts.

20

CHAPTER THREE
LITERATURE REVIEW
3.0. INTRODUCTION TO LITERATURE REVIEW ON REQUIREMENTS
ENGINEERING
The objective of this chapter is to give literature review on system requirements and to explain
how other authors explain the process involved in discovering and documenting these system
requirements, (Pearson, 2011). When you have read this chapter you will meet with the following
sub-titles explaining the whole system requirements engineering: the concepts of functional and
non-functional requirements, requirements specification, requirements elicitation/gathering and
analysis, the principal requirements engineering activities of validation, and the relationships
between these activities.
The process of finding out, analyzing, documenting and checking these services and constraints is
called requirements engineering. A requirement is simply a high-level, abstract statement of a
service that a system should provide or a constraint on a system. At the other extreme, it is a
detailed, formal definition of a system function. Davis (1993) explains why these differences exist:
If a company wishes to let a contract for a large system development project, it must define its
needs in a sufficiently abstract way that a solution is not predefined.

3.1.FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS

A user requirement concerned with security, such as a statement limiting access to authorized
users, may appear to be a nonfunctional requirement. However, when developed in more detail,
this requirement may generate other requirements that are clearly functional, such as the need to
include user authentication facilities in the system. The system requirements therefore do not just
specify the services or the features of the system that are required; they also specify the necessary
functionality to ensure that these services/features are delivered properly.
According to (Pearson, 2011), Software system requirements are often classified as functional
requirements or non-functional requirements as shown below:
3.1.1. Functional requirements, these are statements of services the system should provide,
how the system should react to particular inputs, and how the systems should behave in
particular situations. In some cases, the functional requirements may also explicitly state

21

what the system should not do. A user requirement concerned with security, such as a
statement limiting access to authorized users, may appear to be a nonfunctional
requirement. However, when developed in more detail, this requirement may generate
other requirements that are clearly functional, such as the need to include user
authentication facilities in the system.
This shows that requirements are not independent and that one requirement often
generates or constrains other requirements. The system requirements therefore do not just
specify the services or the features of the system that are required; they also specify the
necessary functionality to ensure that these services/features are delivered properly. These
functional user requirements define specific facilities to be provided by the system.
In principle, the functional requirements specification of a system should be both
complete and consistent. Completeness means that all services required by the user
should be defined.
3.1.2. Non-functional requirements, these are constraints on the services or functions offered
by the system. They include timing constraints, constraints on the development process,
and constraints imposed by standards. Non-functional requirements often apply to the
system as a whole, rather than individual system features or services. They may relate to
emergent system properties such as reliability, response time, and store occupancy.
Alternatively, they may define constraints on the system implementation such as the
capabilities of I/O devices or the data representations used in interfaces with other
systems. Non-functional requirements, such as performance, security, or availability,
usually specify or constrain characteristics of the system as a whole. Non-functional
requirements are often more critical than individual functional requirements. The
implementation of these requirements may be diffused throughout the system.
Non-functional requirements may affect the overall architecture of a system rather than
the individual components. For example, to ensure that performance requirements are
met, you may have to organize the system to minimize communications between
components.

22

A single non-functional requirement, such as a security requirement, may generate a

number of related functional requirements that define new system services that are
required.
3.2.REQUIREMENTS SPECIFICATION
According to (Pearson, 2011), Requirements specification is the process of writing down the user
and system requirements in a requirements document. Ideally, the user and system requirements
should be clear, unambiguous, easy to understand, complete, and consistent. In practice, this is
difficult to achieve as stakeholders interpret the requirements in different ways and there are often
inherent conflicts and inconsistencies in the requirements.
User requirements are statements, in a natural language plus diagrams, of what services the system
is expected to provide to system users and the constraints under which it must operate.
System requirements are more detailed descriptions of the software systems functions, services,
and operational constraints. The system functional specification should define exactly what is to
be implemented.
According to (Pearson, 2011), the system requirements should simply describe the external
behavior of the system and its operational constraints. However, at the level of detail required to
completely specify a complex system, it is practically impossible to exclude all design information.
There are several reasons for this:
a) You may have to design an initial architecture of the system to help structure the
requirements specification. The system requirements are organized according to the
different sub-systems that make up the system.
b) In most cases, systems must interoperate with existing systems, which constrain the design
and impose requirements on the new system.
c) The use of a specific architecture to satisfy non-functional requirements such as N-version
programming to achieve reliability, may be necessary. An external regulator who needs to
certify that the system is safe may specify that an already certified architectural design be
used.

3.3.REQUIREMENTS ELICITATION AND ANALYSIS

According to (Stevens and Pooley, 2006), Requirements elicitation and analysis may involve a
variety of different kinds of people in an organization. A system stakeholder is anyone who should
23

have some direct or indirect influence on the system requirements. Stakeholders include end-users
who will interact with the system and anyone else in an organization who will be affected by it.
Other system stakeholders might be engineers who are developing or maintaining other related
systems, business managers, domain experts, and trade union representatives. Each organization
will have its own version or instantiation of this general model depending on local factors such as
the expertise of the staff, the type of system being developed, the standards used, etc.
The process activities are:
a) Requirements discovery this is the process of interacting with stakeholders of the system
to discover their requirements. There different methodologies used in requirement
discovery. These are interviews and observation and use scenarios and prototypes.
b) Requirements classification and organization.
c) Requirements prioritization and negotiation inevitably, when multiple stakeholders are
involved, requirements will conflict.
d) Requirements specification.
3.4. REQUIREMENTS VALIDATION

According to (Sommerville et al., 1998), Requirements validation is the process of checking that
requirements actually define the system that the customer really wants. It overlaps with analysis
as it is concerned with finding problems with the requirements. Requirements validation is
important because errors in a requirements document can lead to extensive rework costs when
these problems are discovered during development or after the system is in service.
The cost of fixing a requirements problem by making a system change is usually much greater
than repairing design or coding errors.
During the requirements validation process, different types of checks should be carried out on the
requirements in the requirements document. These checks include:
a) Validity checks: A user may think that a system is needed to perform certain functions.
However, further thought and analysis may identify additional or different functions that are
required.
b) Consistency checks: Requirements in the document should not conflict. That is, there should
not be contradictory constraints or different descriptions of the same system function.

24

c) Completeness checks: The requirements document should include requirements that define
all functions and the constraints intended by the system user.
d) Realism checks: Using knowledge of existing technology, the requirements should be
checked to ensure that they can actually be implemented. These checks should also take
account of the budget and schedule for the system development.
e) Verifiability: To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable.
There are a number of requirements validation techniques that can be used individually or in
conjunction with one another:
a) Requirements reviews: The requirements are analyzed systematically by a team of reviewers
who check for errors and inconsistencies.
b) Prototyping: In this approach to validation, an executable model of the system in question is
demonstrated to end-users and customers. They can experiment with this model to see if it
meets their real needs.
c) Test-case generation: Requirements should be testable. If the tests for the requirements are
devised as part of the validation process, this often reveals requirements problems. If a test
is difficult or impossible to design, this usually means that the requirements will be difficult
to implement and should be reconsidered. Developing tests from the user requirements
before any code is written is an integral part of extreme programming.

3.5.THE CONCLUSION OF LITERATURE REVIEW

The above review of the literature on requirement engineering identifies the processes on system
requirement, when this not taken into account can cause project problems and errors. Including problems
of scope the boundary of the system is ill-defined or the customers/users specify unnecessary technical
detail that may confuse, rather than clarify the overall system objectives, second problems of understanding,
the customers/users are not completely sure of what is needed, have a poor understanding of the capabilities
and limitations of their computing environment, they dont have a full understanding of the problem
domain, have trouble communicating needs to the system engineer. Lastly problems of volatility, the
requirements change over time. The rate of change is sometimes referred to as the level of requirement
volatility

25

CHAPTER FOUR
ANALYSIS OF STUDY
4.0.INTRODUCTION TO ANALYSIS
This chapter analyzes different skills acquired, theories learnt in class with what is happening in
the market, experience gained, problem faced and skills lacked during the field practical training
at attained at Catholic University of Health and Allied Science (CUHAS).
4.1.RELATIONSHIP BETWEEN CLASS KNOWLEDGE AND IN MARKET
Although we learn more in class but there is rapid fluctuation of technology. Every day new
technology are being discovered. This changes in order to go with it, there is need of more effort
to be implemented on learning the new technology. This is why there is gaps and problems raised
during field practical training. The theories leant in class help us to open the knowledge of how is
in the market environment.
4.2.SKILLS LEARNT DURING PRACTICAL TRAINING
The following are the skills which I acquired during my field work at Catholic University of Health
and Allied Science.
Computer System Management Skills
There is a clear need to manage systems at all levels. Due to this field training help me to know
how to manage the systems which aim at achieving something system desirable results to the users.
There is a need of managing systems also in the following aspects on system: Risk evaluation,
Backup systems, Particular problems of distributed environments, Importance of good record
keeping and Importance of good communications.
System Development and PC Maintenance Skills
System development need a carefully built, usually by following a project development
methodology that encompasses the life cycle of a project from start to finish. A Web site is never
finished. There are always errors or omissions that were maintained during the development
process. Clients usually find many new uses for a Web site once they have one and request
modifications, additions, and new sections (this is called site maintenance). So at this point, the
project team identifies the new opportunity or enhancement and begins another loop through the
development process.
26

Team Work and Communication Skills

This is the ability of an individual to work together with others, Effective team work consist of
individuals who work together to achieve a common goal or purpose and who hold themselves
accountable for their output. Every individual needs to be well equipped with the tools to
communicate effectively, whether it is on the personal front, or at work. In fact, according to the
management experts, being a good communicator is half the conflict won. After all, if one speaks
and listens well, then there is little or no scope for misunderstanding. Thus, the primary reasons
for misunderstanding are due to inability to speak well, or listen effectively to other.

4.3.SKILLS LACKING
However, the following are the skills that I currently lacking according to the organization
environment:
Technical Job Skills
This refers to the talent and expertise a person possesses to perform a certain job or task. Also
called "hard skills," as opposed to soft skills, which are personality and character traits. Example,
this lay on system development technological changes. New technology arise every day, this make
us to still behind over system development technology.
PC Maintenance Skills
PC maintenance seen to be problem, because some of assigned work was not collect well done due
to low knowledge to it.

4.4.EXPERIENCE GAINED AND CAREER PLAN

In conducting field practical I have revealed various implication between theoretical studies
against practical training, the most of tasks performed I had very interesting because they met most
of desire and aspiration that I got through theory before practical. The skills I gotten tend to
strengthen my working capacity and creativity in working environment. Obviously it was a great
chance to practice all thing I have learned theoretically in the class which simplified and digested
to accumulate skills because most of tasks assigned were more demand analytical creativity in
order to strength my career.

27

CHAPTER FIVE
CONCLUSION AND RECOMMANDATION
5.0.INTRODUCTION
This chapter gives up the conclusion and recommendation on all about field work practice and the
all written in this report. The field work is about the activities done and the skills acquired during
exercise at Catholic University of Health and Allied Science (CUHAS). The conclusion that
contain the major strengths and weaknesses of the field attachment program and benefits derived
from the field attachment program and recommendation part, concerning improving the gaps in
teaching theory and practice and the suggestions to improve the program in planning and
operational logistic.
5.1.CONCLUSION
Accordingly, practical training is imperative, for it is of paramount to both students and to the
institute as a whole. It enhances students to learn and understand many practical training programs
which are not covered in institute and provides the ground for students to strengthen the theoretical
knowledge obtained in classes into practice necessary for their carriers therefore, students can
integrate their theory into practice.
The training exposes students to new challenges and enables students to experience different
working environments before they are actually employed upon completion of their studies.
During my practical training, it has been quite an experience for me to work with IT Department,
by being placed in this organization, I became familiar with the working environment through
understanding its major services, and its activities performed to deliver quality service to their
customers.
Computer System Management, due to changes in technology and advancement of Information
Technology, the Institute has to adopt these changes by restructuring teaching methods of
Computer System courses and supply sufficient project activities to student because the activities
will drive students to meets the organization needs.

28

5.2.RECOMMENDATION
Recommendation to CUHAS
Catholic University of Health and Allied Science (CUHAS) as a university should keep records
through system and not manual as some record are kept manual.
Recommendation to the IFM
As a professional trainee in the IT department at IFM, such opportunity should go with maximum
support to the student on practice with the purpose of integrating the theoretical knowledge and
the working atmosphere in order to create and provide practical learning experience which will
enhance creativity and understanding towards challenges within the profession, Which is basically
achieved through collaborative supervision and unconditioned consultation. Also the institute
should offer more project activities.

29

REFERENCES
1. Whitten and Bentley (2007), System, Analysis and Design Methods, 7th Edition, McGrawHill.
2. Davis, A. M. (1993). Software Requirements: Objects, Functions and States. Englewood
Cliffs, NJ: Prentice Hall.
3. HOOFFER, J. et al. (2006), Modern System Analysis and Design, Dorling Kindersley,
New Delhi.
4. LEE, B. (2003), Introducing System Analysis and Design, Neercy Galgotia, New Delhi
5. CRINNION, J., (1991), Evolutionary Systems Development, a practical guide to the use
of prototyping within a structured systems methodology, Plenum Press, New York.
6. Ian Sommerville. (Pearson 2011), Software Engineering 9th Edition, BBS.
7. Kotonya, G. and Sommerville, I. (1998). Requirements Engineering: Processes and
Techniques.
8. Stevens, P. and Pooley, R. (2006). Using UML: Software Engineering with Objects
andComponents, 2nd ed. Harlow, UK: Addison Wesley.

30