COMPUTER TECHNNICAL SUPPORT SYSTEM

THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE

REQUIREMENT FOR DIPLOMA IN IT

BY

DIT…

NAME

TO

THE DEPARTMENT OF INFORMATION TECHNOLOGY

FACULTY OF SCIENCE AND ENGINEERING AND TECHNOLOGY

ZETECH UNIVERSITY

APRIL 2022

1
DECLARATION

This research project is my original work and has not been presented for any award in any other
university.

I declare the work of the project titled COMPUTER TECHNICAL SUPPORT SYSTEM is based on my own
investigations based on information from sources that stated. I also declare that my work was never
be produced by any student.

Name : ..................................................

Date : ....................................................

Declaration by the supervisor

This Research has been submitted with my approval of the unit supervisor.

NAME :......................…….. ........................................

SIGN :..............……………

DATE :..........…………….

i
DEDICATION

This work is dedicated to God Almighty, my strong pillar, my source of inspiration, wisdom,

knowledge and understanding. He has been the source of my strength throughout this program.

This work is also dedicated to my parents and my lecturers.

Thank you, my love for you all can never be quantified. God bless you.

ii
ACKNOWLEDGEMENT

Firstly, I would like to thank the almighty God for His protection during the entire work. I also
acknowledge the entire school and my supervisor for his guide during the project.

I express my sincere gratitude to the university HOD MR Daniel Njeru for providing an opportunity to
work on a real time project.

I would also thank my parents for their continous support that plays an important role in the
completion of this project.

Appreciation is extended to those individuals who contributed their time and talent to the

development of Basics Of Fleet Magement System for Zetech University.

iii
ABBREVIATIONS

CTSP Computer Technical Support System

iv
TABLE OF CONTENTS

DECLARATION------------------------------------------------------------------------------------------------------------------ i

ACKNOWLEDGEMENT------------------------------------------------------------------------------------------------------- ii

ABSTRACT---------------------------------------------------------------------------------------------------------------------- v

CHAPTER ONE: RESEARCH INTRODUCTION---------------------------------------------------------------------------1

1.1 Executive Summary---------------------------------------------------------------------------------------------- 1

1.2 Research Objectives--------------------------------------------------------------------------------------------- 1

1.2.1 General Objective------------------------------------------------------------------------------------------ 1

1.2.2 Specific Objectives----------------------------------------------------------------------------------------- 1

1.3 Background Information---------------------------------------------------------------------------------------1

1.4 Study Justification------------------------------------------------------------------------------------------------ 1

1.5 Study Limitation-------------------------------------------------------------------------------------------------- 1

1.6 Problem Scope---------------------------------------------------------------------------------------------------- 1

CHAPTER TWO: LITERATURE REVIEW----------------------------------------------------------------------------------- 2

2.1 Introduction----------------------------------------------------------------------------------------------------------- 2

2.2 Global Review--------------------------------------------------------------------------------------------------------- 2

2.3 Regional Review------------------------------------------------------------------------------------------------------ 2

2.4 Local Review----------------------------------------------------------------------------------------------------------- 2

CHAPTER THREE: SYSTEM METHODOLOGY AND DATA COLLECTION-------------------------------------------3

3.1 Introduction----------------------------------------------------------------------------------------------------------- 3

3.2 System Requirements Specification----------------------------------------------------------------------------- 3

3.2.1 Functional Requirements------------------------------------------------------------------------------------- 3

3.2.2 Non Functional Requirements------------------------------------------------------------------------------3

3.3. Design------------------------------------------------------------------------------------------------------------------ 3

3.3.1 Low Level Design------------------------------------------------------------------------------------------------ 3

3.4 Implementation / Development---------------------------------------------------------------------------------3

3.4.1 Language(s), Frameworks and Other Technical Requirements-------------------------------------3

3.4.2 Code Review Strategy----------------------------------------------------------------------------------------- 3

3.5 Testing------------------------------------------------------------------------------------------------------------------ 4

3.5.1 Functional Requirements Testing--------------------------------------------------------------------------4

3.5.2 Non-Functional Requirements Testing--------------------------------------------------------------------4

3.6 Deployment----------------------------------------------------------------------------------------------------------- 4

CHAPTER FOUR: CONCLUSION AND RECOMMENDATIONS-------------------------------------------------------5

4.1 CONCLUSION---------------------------------------------------------------------------------------------------------- 5

4.2 RECOMMENDATIONS----------------------------------------------------------------------------------------------- 5

CHAPTER FIVE: REFERENCES AND APPENDICES----------------------------------------------------------------------6

5.1 REFERENCES----------------------------------------------------------------------------------------------------------- 6

vi
ABSTRACT

In the last few decades, computer support technologies have evolved at a very high pace. As
computer hardware continually evolves and targets greater and more challenging problems, so does
the software that runs on it. One of the latest challenges software developers have is related to the
interconnection of vast numbers of computers and finding ways users can take advantage of this
networking.
One of the ways this was achieved by a group of students, was by developing a collaboration
application, written in Javascript, that students can use to work together. It is described in greater
detail in Chapter 2.

During and after its development a number of development issues arose:

- Resource usage for software updates and distribution: As it was being developed, this application
was updated almost on a daily basis. Due to the software’s nature, it was necessary for users to
always have the latest version. Developing a system to deal with this problem can be expensive and a
waste of resources.

- Cross-platform development compromises: Java is successful at ensuring that the application runs on
several operating systems, but at the same time, it forces developers to program in a way that caters
to the lowest common denominator of all platforms to maintain consistency.

- Data management: As an increasingly larger set of users starts using an application like the
aforementioned one, with a high number of clients (the application follows a client-server model
bandwidth consumption increases drastically

7
Client server model

8
CHAPTER ONE: RESEARCH INTRODUCTION
1.1 Research problem

The manual support of work used alot of time and effort and users had to create time for technical
supporting the work.

Though the system saves the idea, there is still technical skills and knowledge required which can take
so much time for applications without skills to use the software.

1.2 Research Objectives

1.2.1 General Objective

 To come up with an ideal software that could auto-replace mobile app.

 Enhance and boost business processes and school work and manual work.

1.2.2 Specific Objectives

 to change the manual system into a based computerized system which helps the desktop
Application system and easy way for students and institutions and businesses.

 to improve the records of the businesses and education learning

  Ensure the efficient operation of its computer systems and data processing networks

for its staff whether located in the home office, working from international locations, or

telecommuting.

  Minimize spending and maximize the expenditures on technology support

  Enhance the quality of IT support service for IT users

9
  Ensure the security of the computer system infrastructure

1.3 Background Information

This chapter provides the reader with a short overview of the project. It starts by giving a general
description of the state of software development . It then lists a set of issues developers face and
discusses how this project intends to deal with these problems. The last two sections of this chapter
present the layout for the rest of the report and explain what language is going to be used.

1.4 Study Justification

The primary goal for the thesis was to make a complete computer support system for daily use in one
small company, which should confirm all requirements. The demands and requirements for the
system come from the system structure used in our company

10
1.5 Study Limitation

Desktop applications still have a long way to go before they can replace a large number of Phone
support system applications. The following are a few of the areas that should be developed further or
are considered to be “work in progress”.

 User interface components – There are a number of form elements that can be re-used as
components, but there is no support for the creation of custom elements. Some components aren’t
even supported across all operating systems yet.

 Local file access – There is no established platform today to allow the users to read and write to the
user’s file system.

 Streaming media upload support – Support for streaming camera images and sound has existed to
the desktops, but not from.

1.6 Problem Scope

This section summarizes the services to be provided to computer technical support system(CTSP).
CTSP is looking for a firm that will provide long term strategic planning as well as a consistently high
level of IT customer service, maintenance and support. CTSP expects the vendor proposal to define,
in detail, the approach to be used to service and improve its existing computer system infrastructure
and meet future requirements in a cost effective manner.

11
CHAPTER TWO: LITERATURE REVIEW
2.1 Introduction
The chapter provides general understanding of literature reviews of a desktop publishing system as a
case study. The chapter will discuss the conceptual and theoretical development of the system which
means previous works and comparing between the existing systems. The chapter will conclude with
summarizing the chapter with few lines.

2.2 Global Review

FISTY, the Student Sharing Application

(By Lisan Chen)

As a second year project, a number of students at KTH (including the members of this thesis)
developed a project collaboration application in Java.

The program would present an interface where a user can create an account with a username and a
password. When he/she logs in, the user is shown a contact list. To it, he/she may add other users in
the system and send instant messages to them. The focus of the program, however, lies in the project
management. If two or more users wishes to work together, a “project” can be created. A project is
special type of group in the system. Within the project, members can share files, post “tasks” to be
done in the project, and message or chat with other members. An additional feature that was added
to the project was an electronic whiteboard. All members of a group could simultaneously draw onto
this whiteboard and the image would update for everybody.

The purpose was to let students work and study together, despite not being in the same location. The
program was developed in Java 2 Standard Edition, a software platform the development team
believed every student had. The platform’s main advantage was that it did not matter what operating
system users were running. It connected to the project’s own custom server application which in turn
stored all data MySQL Database server that managed accounts and other information (e.g. tasks and
messages).

12
Problems with FISTY

This program worked well and the group succeeded at achieving its objectives with the final version
of the product. Unfortunately, there were a number of issues that could not be solved and had to be
simply ignored, as they lied outside of the scope of the project. To avoid redundancy, the reader is
directed to Section 1.1 of this report, where they are listed. The

following were possible ways to circumvent these issues:

Resource usage for software updates and distribution: To deal with this issue an update server

would have had to be set up with extra bandwidth to not interfere with the rest of the

application’s functions. If this is done, the client would either have to check every time it is

initialized or the server would have to find a way to notify clients after each release. Cross-platform
development compromises: Catering to common standards is understandable – it would have been
wrong of the developer to include features that would only be available to one set of users – but it
worsened the user’s experience when he was forced to use an application that cannot take
advantage of any modern functionality his operating system

provides. The clearest solution would be to develop an application for each platform, but that nullifies
the purpose of using Java in the first place.

Data management: The program did not need all the information it downloaded every time (it would,
for example, download all the messages). An option would be to selectively send only the files and
resources a user needs at a specific moment, which might incur in a high number of requests.
Alternatively, if this becomes difficult to implement, one can extend the host’s bandwidth and
hardware. Finally, one may store the downloaded on the local computer and then attempt to
synchronize the data when a connection is established.

The conclusion the development team came to was that if it would have been forced to turn to these
solutions it would have been better to find other, better-suited tools to accomplish the job with
instead.

13
2.4 Local ReviewCurrent cross-platform technologies
By Gabriel Banfalvi)

There are a large number of platforms that have been developed with the aim of simplifying cross-
platform development. The reader is encouraged to research them further, as they might provide
solutions to the problems he might be dealing with as a developer.

14
 CHAPTER THREE: SYSTEM METHODOLOGY AND DATA COLLECTION
3.1 Introduction

The chapter outlined the methodology that was used in conducting the research. The chapter
presented the research design, target population and sampling techniques that were employed. It
further identified the data collection instruments that were employed in the research and the
procedures for data collection. It concluded by describing how data analysis was conducted and the
output.

3.2 System Requirements Specification

3.2.1 Functional Requirements

• Public has read-only access via website

• API provides read-only data access

• Profile editing requires password-protected user account with manually-assigned rights

• Change log records details on data modification (date, username)

•Consideration will be given to potentially hiding of email address from public view to avoid
collection by

spam senders

User Accounts

• User accounts are password protected (Utilization of InCommon Federation will be considered in
future

phases of development )

• Password reminders and resets are handled by the website

• With the exception of system administrators, all user accounts are tied to an institution
15
Users requirements

1. a strong understanding of the equipment and software needs of an international organization

with offices overseas and whose staff travel frequently to developing countries, which have

limited connectivity and under-developed computer technology;

2. an ability to research and identify software solutions that meet the needs of CTSP staff (eg,

online sharing, webinar system, etc);

3. provide technical guidance and support for videoconferencing platforms (for example, Skype,

Adobe Connect, Google Hangout);

4. identification and resolution of redundancies in CTSP’s current computer system environment

5. effective communication with staff to keep them updated on the progress of troubleshooting

issues

3.2.2 Non Functional Requirements

Accuracy and Validity

The system will employ numerous data quality assurance techniques, including but not limited to:

 • Input masks

 • Drop down lists with standard responses

 • Record data completeness requirements

 • Basic data logic warnings (e.g., Gender: Male with Pregnancy status: Y)

 • Manual review and validation of new draft entity profiles by a designated FDP administrator,
prior to profiles being added to the system.

16
Failure Contingencies

The system is non-critical. Temporary inaccessibility, even up to several days, will not create a
substantial burden on any user. The host site for the system will be chosen so as to include data
backup capabilities and protocols. CTSP will maintain a copy of the code, which has daily backup
protocols.

Sustainability and Open Source Plans

The system will be developed under desktop web development tools and practices.

3.3. Design
3.3.1 Low Level Design

Extending the client-server model

Applications are usually organized by logical parts called “tiers”. Each tier is assigned a role.

Desktop applications usually have a single tier and reside on the client’s computer. Client

server applications on the other hand usually have two or more tiers:

 The client – It acts as a presentation tier which interacts with the user

 The server – It represents the application tier that manages data and business logic.

 The database – Acting as the data tier, storing and retrieving information.

For this project, the application’s tiers would have to be expanded, both in functionality and

number.

4.1.1.1 Layering application tiers

When the application was first planned, one of the main objectives of the team was to
17
modularize the code. It was the team’s intention to allow developers to remove and add

“modules” (the main features) without threatening the integrity of the rest of the program.

Because the application is divided into several tiers, this new modular system would have to

extend over both. Figure 3 shows what it would look like conceptually.

Figur- Client-server model supporting modules

This gave the team the idea to create a basic framework that would:

 Load each module, isolate it and initialize it when the entire program is loaded.

 Handle messaging between the server and the client. It would forward messages

appropriately between modules (e.g. the chat module on the client would contact the

chat module on the server)

18
 3.3.2 High Level Design

The development team decided that the implementation stage should follow a Feature Driven
Development (FDD) process. This would be ideal, because the process is both iterative and
incremental. There are aspects of FDD that cannot be used due to the small number of members (e.g.
code ownership, dealing with all the stages individually), but it was considered that following FDD
would help the team maintain good practices. Figure displays a simplified model of the development
process.

The following would be the team’s interpretation of FDD:

 Develop overall model & build feature list – The overall model would be developed as a list of
features, database schemas, interface mockups and other process diagrams. A list of
interdependencies was made to sort the features by priority.

Plan by feature – The interface mockups would be detailed further, a mock-usability study would be
performed through hallway testing (people would be brought in and would test mock-ups and discuss
the component that was being developed) and meetings would be held about relevant aspects of the
implementation. These features would then be divided into smaller, more manageable tasks
(resembling user stories). This way, team members would be able to split up work according their
speed.

19
Sequence Diagram of File Upload

20
21
3.4 Implementation / Development
3.4.1 Language(s), Frameworks and Other Technical Requirements
Hardware interface requirements

Processor speed of 0.5Ghz or mobile gadget.

Processor of speed 1.5ghz or more for desktop and computer gadgets.

Ram of 500mb and above for all the devices

Free storage memory capacity of more than 100mb.

Sofware requirements

OS: Windows,linux,ubuntu

Software: visual studio code,xampp,wamp.

Front end: JS/CSS

Back end: PHP.

Database : MSQL

22
Computer Infrastructure and Environment

1. Server. ICRW servers are located onsite at its home office. Server specs

are as follows:

23
2. Backup: CTSP currently has daily back up through Iron Mountain as well as our current support
service vendor.

3. Computer equipment: All CTSP employees are being transitioned from desk top DELL PCs to lap
top computers. The lap tops are installed with a wireless mouse, 19 (nineteen) inch monitor and
docking station. This is the current standard set up for each employee at CTSP. Set up in our Asia
Regional Office is handled by our local IT staff while set up in our Africa Regional Office is currently
handled remotely

Operating System: Most lap tops have Windows 10 as the operating system but some

of our “loaner” lap tops still run Windows 7.

Software: Windows Office 2016 (Office365) and Adobe 10 (with e-signature capability and set-up)

Antivirus Software: ICRW is currently using Kaspersky Antivirus 10.2.5.3201 (mr3) and a software
known as ‘Agent’ utilized by our current vendor in order to remote into any computer devices.

5. Internet: CTSP has a dedicated hosted internet access. Our service provider is Allied Telecom.

Wireless Access Points: We currently have 5 CISCO Meraki MR32 WAP devices, which are used
throughout the office for wireless connection.

Telecommunications: ICRW has an analog telecommunications system. CTSP currently uses Avaya as
its standard telephone model. We currently use Avaya 5410 POTS; AVAYA IP Office Manager 5.2(54).

Cell phone support: ICRW currently uses AT&T as its cellular phone provider. IT support is required
primarily to help users sync cell phones with email and calendars and troubleshoot when users
experience difficulty with their phones. ICRW issued phones are either Apple iPhones or LG Droid
phones. We currently have 20 iPhones and 5 LG Droids

Email system: ICRW has recently transitioned to Office 365 as its’ cloud based email system. CTSP
uses Outlook.

24
Share File System: CTSP currently uses Citrix to access files remotely. While we are moving towards a
cloud-based system, we have yet to identify the appropriate platform for the institution. ICRW would
like to transition to a user friendly shared file platform. Currently we use Citrix XenApp version 6.0.0.0
which is an outdated version since the current citrix version is 7.12.6

Financial management software: CTSP currently use Solomon as its accounting software and
UNANET as the program management software. We are in the process of transitioning both of these
applications to an offsite host in order to relieve the problematic communication we have
experienced between the two platforms.

Videoconferencing. CTSP currently has recently selected Adobe connect as our video-conferencing
software. We have utilized go-to-meeting with some success and we are currently in the process of
exploring Skype for business along with others.

B.Website Maintenance Requirements

1. External online presence. CTSP’s organizational website is built on a WorldPress platform and is
hosted by Motivate Design, who also maintain the site. The domain host is Network Solutions.

2. Intranet. CTSP’s intranet site is built on Drupal v. 6 and is hosted by Liquid Web. It is considerably
out of date and currently, no one on staff has the skills to maintain it.

25
3.4.2 Code Review Strategy
Configurations of the system:

To start with application, it is first needed to conFigure, install and run all packages. While running it
in LINUX Top system, it is needed to install these packages on

sudo apt-get install \

TRAC \

php-mysqldb \

php-psycopg2 apache2 \

libapache2-mod-wsgi \

libapache2-mod-python \

libapache2-mod-php5 \

libapache2-mod-authnz-external \

libapache2-mod-authz-unixgroup \

pwauth \

php5-mysql \

php5-svn \

mysql-server

26
3.5 Testing

3.5.1 Functional Requirements Testing

Testing was carried out based on the relevant review of the system to find bugs such as incorrect

functions, ensure that it is complete and accurate which was followed by full system testing to

ensure that all units function effectively as a single system.

Validation was carried out by taking the system to the users to check whether it meets their

requirement

Prototyping is used to leverage the involvement of end-users in waste disposal system testing.
Prototyping produces a preliminary version of the required system that can be reviewed by end-
users. After review, the prototype is added to and altered to produce another version closer to the
one that is wanted.

The Figure gives a diagram of prototyping process

27
 3.5.2 Non-Functional Requirements Testing

Are qualities of the solution.they consist of the solution limitations or the implementations
constraints and external factors such as system availability.

 Flexibility

 Intergrity constraints

28
CHAPTER FOUR: CONCLUSION AND RECOMMENDATIONS
4.1 CONCLUSION

This thesis intended to research how viable computer technical support system helps in the carrying
out IT support technical and minimizes work loads. To do this an attempt was made to convert a
desktop application into a web application and research new potential technologies. Though
performance is satisfactory and most programs can be rewritten for the web browser, developers
must be research the software platforms they are going to use and gain significant experience.

4.2 RECOMMENDATIONS

The result of the project responded to the customer‟s expectations. companies were satisfied with
the features implemented and their reliability and robustness. Through the thesis and development
process I gained quite good experience, of an overall structure of different systems and the basic
concept of the system as whole. It was quite challenging to improve already made system as

CTSP while adding there new features and to put CTSP to work with new functions. New ideas of
what more to improve or how to improve the system and what kind of new features to add, come up
through the development of thesis. For example there has been an idea, to make search functionality
to project, which will help users to search projects by date or by creator of a project. During the
process of implementation, wonderful ideas have been got and hopefully in a near future, there is a
possibility and time allocated to improve the system.

29
CHAPTER FIVE: REFERENCES AND APPENDICES
5.1 REFERENCES

DFind Port Scanner. (n.d.). Retrieved 18 7, 2011, from Heap Overflow:

http://heapoverflow.com/f0rums/projects/tools/20-dfind-port-scanner/

Google Trends. (n.d.). Search trends for Adobe Air, Web applications, Adobe Flash and .NET.

Retrieved July 22, 2011, from Google Trends:

http://www.google.com/trends?q=adobe+air%2C+web+application+|+web+app+|+we

b+applications+|+web+apps%2C+macromedia+flash+|+adobe+flash%2C+%22.net+fra

mework%22&ctab=0&geo=all&date=all&sort=0

Icaza, M. d. (2011, May 16). Announcing Xamarin. Retrieved July 28, 2011, from Tirania:

http://tirania.org/blog/archive/2011/May-16.html

Kerner, S. (2011, May 03). Attachmate lays off Mono employees. Retrieved June 21, 2011, from

InternetNews: http://www.internetnews.com/skerner/2011/05/attachmate-lays-off

mono-emplo.html

Ludwig, A. (2009, January 28). Adobe AIR and Adobe Flash Player Team Blog. Retrieved May 23,

2011, from Adobe:

http://blogs.adobe.com/flashplayer/2009/01/air_passes_100_million_install.html?sdid

=EENC

Lung, C. (2011, February 23). Installing Node.js and NPM on Ubuntu 10.10. Retrieved June 22,

2011, from Giant Flying Saucer: http://www.giantflyingsaucer.com/blog/?p=2284

30