A WEB-BASED NETWORK MONITORING SYSTEM

THAT ENABLES MONITORING AND MANAGEMENT

OF NETWORK INFRASTRUCTURE AND RESOURCES.

MAJOR PROJECT PROPOSAL

ABU BAKARR SIDIQUE TURAY………...................905002413

ALIM KARGBO…………………………………….…...905002415

OSMAN ADIKALIE KAMARA………………….……..905002414

YEAR 2023

FACULTY OF INFORMATION & COMMUNICATION

TECHNOLOGY

LIMKOKWING UNIVERSITY OF CREATIVE

TECHOLOGY SIERRA LEONE

MAY 2023

i|Page
 DECLARATION

We hereby declare that except the work of other researchers which are duly
referenced, this submission is the result of my own work under the supervision
of Mr. Abass and that this has neither been presented in whole nor part
elsewhere for the award of any other degree or diploma of a university or other
institution of higher learning.

Names:
Osman H. Kamara , 905002414
Signature……………………. Date……………………
Abu Bakarr S Turay, 905002413
Signature………………………. Date……………………
Alim Kargbo, 905002415
Signature………………………… Date……………………

ii | P a g e
 ABSTRACT

This development presentation is of an information system for the network device

monitoring system for Yaba Tech SL. The easy to use system is named the Network
Device Monitoring System (NDMS). The culmination of the system transition hinged
on calming problems that stemmed from the old manual system. NDMS employs
Graphical User Interface functionalities, an application server and a database server.
The system has SQL Server as the back end. The Integrated Development
Environment was PHP. Connectivity was offered through Microsoft windows 2018
with application server roles configured. The system can run on standalone Desktop
Windows Operating Systems. In a bid to address the problems of the old system a
sound alert notification service to the engineers is incorporated, outage records are
automatically recorded and outages are quickly detected. The problem was defined
in chapter one. The feasibility study justified why the system should be developed
and is discussed in chapter two. System analysis was also considered to produce a
user- oriented system and user requirements in Chapter three. System design
modelled the system and lastly system implementation and testing brought to life the
conceptualized system. Lastly, experiences and observations for the future were also
analyzed and presented.

iii | P a g e
 ACKNOWLEDGEMENT

We are very grateful to God Almighty for been there for we throughout our
studies. Without God, this work would have not been a success as he gave,
we the strength and courage required in every step during our study and
also for long life and good health. To him we give honor, praise and glory.
We sincerely express special thanks to our energetic supervisor for his
guidance, understanding, and patience and most importantly, he has
provided positive encouragement and warm spirit to finish this study. It has
been a great pleasure and honor to have him as my supervisor. We must
express our sincere gratitude to all the lecturers in the faculty of information
communication technology, Limkokwing University of Creative Technology
for their guidance and knowledge they inculcate in we. Special thanks to all
my friends for their moral support, especially Joshua Yarjah we would like to
thank everybody who was important to the successful realization of this
Project, as well as expressing my apology that we could not mention
personally one by one. God shower his blessing on you all. Finally, in term of
any error or lapses found in this work I whole heartedly take full
responsibility

iv | P a g e
 TABLE OF CONTENT

DECLARATION.....................................................................................................................ii
ABSTRACT............................................................................................................................ iii
ACKNOWLEDGEMENT......................................................................................................iii
LIST OF FIGURES.................................................................................................................5
LIST OF TABLES...................................................................................................................6
LIST OF APPENDICES......................................................................................................7
1.1 Introduction................................................................................................................8
1.2 Background of the study..........................................................................................10
1.2.1 Background of organisation..............................................................................8
1.2.2 Organizational Structure...................................................................................9
1.2.3 Vision...................................................................................................................9
1.2.4 Mission Statement..............................................................................................9
1.3 Problem Statement Problem Definition...................................................................9
1.4 Project Aim.................................................................................................................9
1.5 Objectives..................................................................................................................10
1.6 Methods and Instruments........................................................................................10
1.7 Project Justification.................................................................................................10
1.8 Analysis of Feasibility..............................................................................................13
1.8.1 Technical Feasibility........................................................................................13
1.8.2 Economic Feasibility........................................................................................15
1.8.3 Social Feasibility...............................................................................................16
1.8.4 Operational Feasibility....................................................................................16
1.9 Risk Analysis.............................................................................................................17
1.10 Work Plan.................................................................................................................18

2. CHAPTER THREE: ANALYSIS PHASE..................................................................20

2.1 Introduction of the chapter content........................................................................20
2.2 Information gathering methodologies....................................................................20
2.3 Analysis of existing system......................................................................................22
2.3.1 General description of the current system.....................................................22
2.3.2 Inputs.................................................................................................................22
2.3.3 Processes............................................................................................................23
2.3.4 Output...............................................................................................................23
2.3.5 Activity diagram of current system................................................................24
2.3.6 DFD of current system.....................................................................................25
2.4 Weakness...................................................................................................................25

v|Page
 2.5 Evaluation of Alternatives.......................................................................................25
2.5.1 Outsourcing......................................................................................................25
2.5.2 Improvement of current system......................................................................26
2.5.3 Development.....................................................................................................26
2.6 Requirements Analysis............................................................................................27
2.6.1 Functional Requirements................................................................................27
2.6.2 Functional Requirements................................................................................28
2.6.3 Non-Functional Requirements........................................................................29
2.7 Conclusion.................................................................................................................29
3. CHAPTER FOUR: SYSTEM DESIGN.......................................................................30
3.1 INTRODUCTION....................................................................................................30
3.2 SYSTEM DESIGN...................................................................................................30
3.3 ARCHITECTURAL DESIGN................................................................................32
3.4 User Interface design...............................................................................................34
3.4.1 Menu Design.....................................................................................................34
3.4.2 Input Design......................................................................................................35
3.4.3 Output Design...................................................................................................36
3.5 PROCESS DESIGN.................................................................................................36
3.6 PROGRAM DESIGN..............................................................................................37
3.6.1 Class Diagram...................................................................................................38
3.6.2 Sequence Diagram............................................................................................39
3.6.3 Collaboration....................................................................................................40
3.6.4 Pseudocode........................................................................................................40
3.7 DATABASE DESIGN..............................................................................................42
3.8 SECURITY DESIGN...............................................................................................45
3.9 BACKUP DESIGN...................................................................................................46

vi | P a g e
 lOMoARcPSD|26463657

3.9.1 Onsite backup...................................................................................................46

3.9.2 Offsite backup...................................................................................................46
3.10 TEST DATA DESIGN.........................................................................................46
3.11 DEPLOYMENT DESIGN...................................................................................47
3.12 Conclusion............................................................................................................47
4. CHAPTER FIVE: IMPLEMENTATION...................................................................48
4.1 Introduction..............................................................................................................48
4.2 System Specifications...............................................................................................48
4.2.1 Software Specifications....................................................................................48
4.2.2 Hardware specifications..................................................................................49
4.3 Testing.......................................................................................................................50
4.3.1 Test Data Results..............................................................................................50
4.4 Installation and Conversion....................................................................................52
4.4.1 System training.................................................................................................54
4.4.2 System installation and User Acceptance......................................................55
4.5 Maintenance..............................................................................................................55
4.5.1 Maintenance Strategies....................................................................................56
4.6 Performance Analysis..............................................................................................56
4.7 Recommendations....................................................................................................57
4.8 Conclusion.................................................................................................................57
Reference list...........................................................................................................................58
Appendix A: User Manual.....................................................................................................59
Appendix B: Interview Checklists........................................................................................66
Appendix C: Questionnaires.................................................................................................67

7|Page
 lOMoARcPSD|26463657

Chapter 1:
Introduction

Introduction Computer networks are connecting millions of computers and computer

users throughout the world. The network has become an infrastructure for many
applications that affect our daily lives. It is very important that the computer network
needs to be managed properly.
Management of networking requires monitoring. Network monitoring is a set of
mechanisms that allows network administrators to know instantaneous state and long-
term trends of a complex computer network. Network monitoring and measurement
have become more and more important in a modern complicated network.
In the past, administrators might only monitor a few network devices or less than a
hundred computers. The network bandwidth may be just 10 or 100 Mbps; however,
now administrators have to deal with not only higher speed wired network (more than
10 Gbps and ATM (Asynchronous Transfer Mode) network) but also wireless
networks. They need more sophisticated network traffic monitoring and analysis tools
in order to maintain the network system stability and availability such as to fix network
problems on time or to avoid network failure, to ensure the network security strength,
and to make good decisions for network planning.
Network Monitoring involves multiple methods which are deployed on purpose to
maintain the security and integrity of an internal network. The internal network is also
known as a Local Area Network (LAN) and monitoring encompasses hardware,
software, viruses, spyware, vulnerabilities such as backdoors and security holes, and
other aspects that can compromise the integrity of a network. Network monitoring is a
difficult and demanding task that is a vital part of a network administrators job.
Network administrators are constantly striving to maintain smooth operation of their
networks. If a network were to be down even for a small period of time, productivity
within a company would decline, and in the case of public service departments the
ability to provide essential services would be compromised. In order to be proactive

8|Page
 lOMoARcPSD|26463657

rather than reactive, administrators need to monitor traffic movement and performance
throughout the network and verify that security breaches do not occur within the
network.
When a network failure occurs, monitoring agents have to detect, isolate, and correct
malfunctions in the network and possibly recover the failure. Commonly, the agents
should warn the administrators to fix the problems within a minute. With the stable
network, the administrators' jobs remain to monitor constantly if there is a threat from
either inside or outside network. Moreover, they have to regularly check the network
performance if the network devices are overloaded. Before a failure due to the
overload, information about network usage can be used to make a network plan for
shortterm and long-term future improvement.
Networks have improved from connection between a few appliances to connecting
number of appliances in various LANS, which lead to emergence of internet
technology. Internet technology has become very important as businesses heavily rely
on it. Proactive monitoring of interconnected devices has become so vital in the
internet service provision business, hence the need for network monitoring systems by
organizations. The term Network Management refers to monitoring and controlling the
connected devices in a particular network. There is a requirement to have a real time
performance and agentless monitoring system that alerts and reports outages,
latencies and packet losses for Internet Service Providers backbone devices. This
project seeks to address all those above-mentioned requirements.
Network monitoring takes note of slow or failing systems and notifies the network
administrator of such occurrences. Such notifications can take the form of email
massage, page alerts, or plain old phone calls. No matter what form they take, network
problem massage should take the highest priority. Network monitoring should be
running while other systems are performing their functions that is vital. As computer
networks grow in size, both physically and geographically day by day, more scalable
solutions for network administration are becoming necessary to monitor bandwidth
usage, report and resolve network failures and analyzing user activity. The proper
solution may support system administrators to make decisions for their future

9|Page
 lOMoARcPSD|26463657

expansions, preventing system failures and maintaining efficient internet band width.

Background

This research to think of better ways of getting reports, alerts, and statistics of its
backbone network devices. At the present moment outages are going unnoticed for
hours, there is no system to check quality of connectivity. The researcher desires to
come up with a system that collects ICMP stats, analyses, alerts, as well as reporting
outages to the network and system administrators. Time consumed to do manual pings
and reports will be a thing of the past once this system is successfully implemented. All
in all, the author would want to transform this organization into a modern Internet
Service Provider (ISP) like the likes of Afcon, IPtell, Orang and Africell which has
automated Systems
that reduces workload at the same time improving efficiency and effectiveness.
Networking and IT Professionals today have a tremendous responsibility when it comes
to managing the network of a higher-education campus or organization. The massive
growth of stored data (and the need to share it) is constantly placing pressure on an
already over-stressed network. The unpredictable student user base is prone to network
misuse and security breaches. Educators are looking to further leverage networked-
based learning tools and streaming video. Campus administrators are adding new
applications while demanding more and more remote accessibility; and campus legal
departments are anxious to ensure that campus networks are meeting all government
and other security and privacy regulations and compliancy—while constantly making
requests for network usage reports and other network activity to assist in copyright
protection efforts. The growing dependence on networks for everyday tasks has created
the demand for high performance; reliable networks thereby making companies invest a
lot on research on improving the networks and new designs. Part of achieving the goal
of high performance is active monitoring of networks to help in the identification and
prevention of network errors. Many tools have emerged to aid in performance
monitoring of networks. The most common class of tools is based on the Simple

10 | P a g e
 lOMoARcPSD|26463657

Network Management Protocol (SNMP), a protocol for sending and transmitting network
performance information on IP networks. Other types of network performance
monitoring tools include packet sniffers, flow monitors and application monitors.

11 | P a g e
 lOMoARcPSD|26463657

Problem Statement

This research is aimed at confirming the assertions that there are no technically enforced
restrictions on what network traffic can go into or out of most networks. There are rules and
regulations which users agree to abide by, but if they choose to ignore these, they are able to
do so. This also makes the network more vulnerable to viruses and advanced hackers of the
21stcentaury. Inappropriate traffic can slow the network down, or even bring it to a complete
shutdown, causing frustration to legitimate users of the network. Illegal traffic, such as pirated
movies and music, can get both the Organizations and the individual users into serious
litigation. To an extent network abuse is inevitable. In most organizations and especially
academic institutions, it is very difficult to impose technical restrictions on network traffic. In
corporate networks ‘acceptable’ traffic can often be clearly defined. This is not the case in
colleges or learning institutions. Almost any port might be required for some reasonable
purpose so simply banning traffic by port would be difficult. Restriction by type would be hard
too – for example peer to peer software is used by research groups for ease of collaboration,
as well as by users sharing copyright material.
Systems and network administrators are burdened with fighting fires when something goes
wrong on the network. They have no information of what may have caused a network failure.
This is more so on computer networks that do not have any high-grade network monitoring
software installed. This scenario is common place in academic institutions because of the
aforementioned reasons. This was the inertia for this research and project development.

12 | P a g e
 lOMoARcPSD|26463657

Network Monitoring Systems Monitoring helps network and systems administrators identify
possible issues before they affect business continuity and to find the root cause of problems
when something goes wrong in the network. Be it a small business with less than 50 nodes or
a large enterprise with more than 1000 nodes, continuous monitoring helps to develop and
maintain a high performing network with little downtime. For network monitoring to be a value
addition to a network, the monitoring design should adopt basic principles. For one, a
monitoring system should be comprehensive and cover every aspect of an enterprise, such
as the network and connectivity, systems as well as security. It would also be preferable if the
system provides a single-pane-of-glass view into everything about the network and includes
reporting, problem detection, resolution, and network maintenance. Further, every monitoring
system should provide reports that can cater to a different level of audiences—the network
and systems admin, as well as to management. Most importantly, a monitoring system should
not be too complex to understand and use, nor should it lack basic reporting and drill down
functionalities.

When networks grow and become considerably large such as for the UNZA, it becomes
infeasible for one person to maintain a mental model of the entire network. When this
happens, the network is an unknown entity where faults could occur at any time and not be
detected by network operators. A Network Monitoring System is a software package used to
solve this debacle and diagnose faults on the network. It achieves this by storing an internal
model of what the network is supposed to be and uses this model to evaluate the current
state to the network. This enables the network monitoring system to provide insight into the
otherwise unknown entity. The system also provides performance data on how well the
network is utilized and answers questions regarding economics, i.e. is the network cost
effective and meeting demand? A network monitoring system should be able to monitor all
these occurrences on the network without putting undue load on the devices being monitored.
Not many network monitoring system are able to achieve this feature. Different techniques
can be used by network monitoring system to monitor a network. The rest of this section
focuses on the features required in an ideal network monitoring system and those that should
be provided to produce a general purpose network monitoring system.

13 | P a g e
 lOMoARcPSD|26463657

2.1 Introduction
Gill harm (2002) defines planning phase as a sketching out of the work to be
performed. Amid this phase, a group ought to prioritize the undertaking, Figure
a funding and plan, and also a Figure of resources that were needed to come
up with the project. The researcher defines in detail what to build, the personnel
involved in the building, how the solution should be built and when it should be
built. It is in this phase that the researcher works through the design process
and come up with design and architecture. Cost estimates, work plans,
functional specifications and various deliverables were also scheduled in this
phase. The researcher’s goal was to document the solution to a degree which
was produced and deployed in a cost-effective and timely manner. A number of
Methodologies, Cost benefit analysis techniques was used to evaluate if the
project undertaken was profitable in the long run considering the business value
of the system.

2.2 Business value

Yaba Tech SL aspires to be seen by their clients as a trusted Business Advisor.
As a measure to fulfil this goal, this project will unlock the below business value
that will benefit the organization to be the leading Internet Service Provider in
Zimbabwe.

Tangible values
 The monitoring tool will provide the right level of management reports
needed to keep track of the health of Yaba Tech SL IT environment.
 Reduced cost and impact of downtime. Downtime can cause Yaba Tech SL
to lose money, because their network devices directly contribute to revenue
as their core business is to provide Internet services.
 The business experiences a return on their investment typically in just a few
months as there will be faster time to resolution and time savings for IT
personal during diagnosing network issues.

Intangible Values:
 Improved customer satisfaction, as the first line support is able to detect
down time and alert the network engineers.

14 | P a g e
 lOMoARcPSD|26463657

15 | P a g e
 lOMoARcPSD|26463657

 Availability of statistical information about devices uptime and down time

that will help the organisation to analyse and make improvements
2.3 Analysis of Feasibility
Feasibility study addresses the below issues:
 To establish whether the project is operationally, technically, socially
and economically feasible.
 To establish whether the benefits outweighs the costs.
 To see if there is schedule feasibility.
 To establish strength and disadvantages of the existing system.
 Establish the proposed system.
 Find out the requirement specifications.
 Explore the specific objectives of the proposed system

2.3.1 Technical Feasibility

The analyst explored the following areas as a way of assessing the technical
feasibility of the project:
 Does the system to be developed use technologies accessible to the firm?
The project has been considered technically viable since the technology
employed is available in Zimbabwe and the will make use of it without any cost.
Is the hardware to be employed accessible?
The servers are locally available at affordable prices.
Is the hardware and software compatible?
The system can adequately provide all demanded services the users may need
and there is room for expansion in case more needs arise.

Software specifications
To ensure the viability of developing the system the below technical aspects
must be evaluated.

16 | P a g e
 lOMoARcPSD|26463657

Table 1 Software specifications

Item Available Not Comment

available
Windows operating Complete set

system (Windows present
Server® 2012 R2 SP1
Enterprise)
PHP Not available


Table 2 Hardware requirements

Item Available Not Comment

available
Dell r720 server  Available Full
set.
Hard drive (500GB-  Available Full
1TB SAS Hot- set.
plug Hard Drive.)
Processor (12GB  Available Full
DDR3) set.
42 gig Ram.  Not available

2 RJ45  Not available

One metre long  Not available

Ethernet cable.
Power cables and surge  Not available
protectors

17 | P a g e
 lOMoARcPSD|26463657

2.3.2 Economic Feasibility

The analyst explored the following areas as a way of assessing the economic
feasibility of the project:

Operational Costs: On-going costs of using and maintaining the system.

Table 3 Operational Costs

Year 1 2 3
Benefits Values Values ($us) Values ($us)
($us)
Drop in first line support 2200 2200 2200
team size
Reduced service level 7000 7000 7000
agreements penalty
Expected increase in 6000 7000 8000
revenue
Yearly Total 15200 16200 17200

Costs Values Values ($us) Values ($us)

($us)
Project team expenses 3000 No expenses No expenses
Initial Cost 285 No expenses No expenses
Operational Costs 500 1200 4000

Total 3785 1200 2000

Benefits Less Costs 11 415 15000 152000

18 | P a g e
 lOMoARcPSD|26463657

Capital Investment Analysis

ROI =Returns on Investments
ROI= (Total Discounted Benefits – Total Discounted
Costs) Discounted Costs
= (26 000 –22 000) X 100 = 18.18%
22 000
 The higher the ROI the better. This project shows a relatively high ROI
which means it is highly economically feasible.
 Life time benefits are expected to exceed life time costs making the
projects viable to implement.
Costs
Systems Developers Cost: These are the funds which are charged by the
system developers. In this case no internal developers were hired hence only
overtime expenses will be incurred.
Initial Costs: These are costs associated with starting-up the new
network device monitoring solution.

2.3.3 Social Feasibility

The introduction of the new system does not seem to bring much problem to the
social structure of the firm neither does it compromise the morals and the general
organizational culture as the bulky of the population is made up of a younger
generation who can quickly empress technology.

2.3.4 Operational Feasibility

A systems request is operationally feasible if it is highly likely that the system
will be used once it has been developed and implemented and that it is going to
be adequate to meet all operational needs with ease.
Below are the parameters used by the researcher during their analysis of the
operational feasibility of the system.
Do the various stakeholders of the firm support the project?
 Top Management: The management team headed by the organization
CEO and his top management, the financial director and the ICT manager
are fully behind the new system as it will reduce the risk of losing
customers to fierce industry rivals due to lack of reactiveness.

19 | P a g e
 lOMoARcPSD|26463657

 System administrators: They are also advocating for this option since it
will bring ease to the analysis of client data for decision making as well as
enabling them to be proactive.
 First level support: It will be much quicker to detect outages and reduces
time wasted troubleshooting.

2.4 Risk Analysis

As with any other project there are risks involved which is those factors that
undermine the development of the system. The following section identifies and
assesses the risks, as well as coming up with ways to avert these risks and to
monitor all circumstances that may lead to the risks. Risk management is
very critical because if ignored, and these risks do happen they can delay the
project, increase the project costs, or even worse cause the project to be
abandoned.
Budgetary Risks
 Due to the current economic situation in Sierra Leone, there is great
uncertainty about availability of foreign currency to buy servers as this now
requires approvals from BSL. On whether the application will be approved or
not and given priority lies in the hands of BSL.
 Inflation risk cannot be ruled out. Prices can double or triple within a short
space of time meaning things would not flow as per budget.
 Prices of computer accessories are changing each and every day and this
can have adverse effects on the success of the project.
However, the good news is that there is another supplementary budget that has
been set aside by management so as to counter for such unexpected rises in
prices and ensure the success of the project.
Time Factor:
There are fears that the project may fail to finish within the anticipated time.
This is because of unforeseeable factors such as illness or other demanding
factors such as issues like bereavement leaves by the developer. To counter
for this risk, there are more people with system development and project
management skills in the project team. Effort has been made to utilize the time
wisely, economically and efficiently so that disturbances will come after
covering as much ground as possible.

20 | P a g e
 lOMoARcPSD|26463657

21 | P a g e
 lOMoARcPSD|26463657

Technical Risks
There is a risk that the system may not meet the user requirements in that
users might find it difficult to maintain the system or restore it in the event of a
crash.

2.5 Work Plan

Table 4 Work plan

Activi 1 2 3 4 5 6 7 8 9
ty/
We
ek
Project
Analysis
Project
Design
Coding/Co
nstruction
Testing
Implement
ation
Maintenan
ce
Sign-Off
Document
a
tion

2.6 Conclusion
To reach an informed choice numerous feasibility studies were done these
included the technical feasibility, operational feasibility, economic feasibility as
well as the organizational feasibility. Within the economic feasibility the cost
benefit analysis was conducted using the Net Present Value (NPV), Payback
period and Return on Investment (ROI). In any of the instances the project was
noble. In a bid to have a balance of judgement risks were explored and
mitigating measures were subscribed to allay the impact of the stated risks.
22 | P a g e
 lOMoARcPSD|26463657

Chapter 2: System Requirements and Analysis

Introduction of the chapter content
It involves gathering information from users through various techniques such as:
 Interviews
 Brain storming
 Lecture reviews.
In addition, system analysis involves breaking of complex activities that are involved in
the entire system and location of data stores. The most significant objective of system
analysis is finding solutions to complications for each business activity. Questions like
what, who, where and how are answered. The process is more of a rational activity and
requires the researcher to think outside the box. The end result of this process is a
rational system design. In short system analysis refers to the process of assembling and
translating facts, establishing the problems, and decomposition of a system into its
elements.
Below activities were involved in this phase:
 data assembling methodologies
 Inspection of data assembling methodologies
 Evaluation and clarification of results
 Examination of current System
 Current systems data flow diagrams and context diagram.
 Pros and Cons of existing system
 Requirements Specifications and Constraints.

2.7 Information gathering methodologies

The major objective of this phase was collection of detailed information from the
existing system users. Existing system users included stakeholders, for instance
company workers, shareholders and customers. Gathered views and ideas were merged
into the design stage. This processes objective shed more light on the user’s
requirements and restrictions of the existing system. Various types of data gathering
techniques were used. Below are the research methods used in gathering information:
 Personal interviews
 Questionnaires

23 | P a g e
 lOMoARcPSD|26463657

Personal Interviews
Interview involves a direct conversation between two or more individuals
concerning a certain topic (Sauter, 2013). An interview consists of the interview
which is the one being asking questions to the other part and the interviewee
providing answers. To add, interviews enable direct interaction that is, face to
face meeting with the participants of existing system (Kvale 1996). The
researcher implements the following steps when conducting interviews at Yaba
Tech SL Makeni branch:
 Selecting individuals to be interviewed
 Designing questions to be answered.
 Interview process
Selecting Individuals to be interviewed: individuals were chosen based on
their influence and relevance in the network monitoring system being used by
the organization.
Designing questions for the interview: The analyst drafts the questions that
need to be answered. The transcript of questions for the interview conducted is
found in the appendix section.
Interview process: Individuals to be interviewed were selected and the
questions were designed then, the interviews were conducted. Individuals who
were willing to provide reliable information and understand the operations of the
existing system were interviewed.

Advantages of interviews
 The method was quick and precise since collection of information was noted
down as it was said.
 It allowed the analyst to take note of social cues from interviewees such as body
language and facial expressions, thus gathered data from merely observing the
cues.
 It also allowed for probing of answers quickly through direct questioning.
 The interviewer was given room for motivating his interviewee so that they
respond freely and honestly.
Disadvantages of interviews
 Interviews were time consuming to recruit and conduct
 As a result of timing and travel, interviews were expensive
 Information from the respondents was captured manually, hence more work
and time consumed.
24 | P a g e
 lOMoARcPSD|26463657

 It was difficult to conduct a large number of audiences

Questionnaires
Questionnaires are mainly used when the researcher wants to conduct a large
number of audience or groups (Kvale, 2014). It is another fact finding
techniques in which the questions are formulated by the researcher and printed
to be distributed among the targeted group. In this case the researcher printed
a number of questions and the questions were distributed among the staff
involved in the operations of the existing surveillance system. The questions
were designed with a choice of answers for it to easier for the participants to
understand the answering technique (Steele, 1996).
Advantages
 Less time was consumed since the questions were distributed to the
audience at the same time.
 It provided flexibility for the participants to express their feelings and views
towards the system unlike interviews.
 It was easy to compare questionnaires.
Disadvantages
 Some of the participants failed to understand the questions resulting in
wrong answers.
 The results may be meaningless if a small size of participant respond.

2.8 Analysis of existing system

2.8.1 General description of the current system

The organisation relied on manual checking of network device up time as they
did not have a system to automatically alert and report outages. Manual pings
and traceroutes were done routinely to check network devices availability.
 With the existing setup there was no way to proactively determine uptime of
network devices.
 It was difficult to carry out device availability reports as there was no system to
show historical trends of network devices.

2.8.2 Inputs
This is the data that is put into the current technical support, network and system
engineers.
 Network device details such as IP address and description or name.

25 | P a g e
 lOMoARcPSD|26463657

26 | P a g e
 lOMoARcPSD|26463657

2.8.3 Processes
 Manually performing pings and traceroutes at random periods to check
network device status.
 Recording uptime statistics of network devices on excel sheets.

2.8.4 Output
 Recorded network devices details.
Recorded uptime statistics of network devices

2.8.5 Activity diagram of current system

Network
Escalates to Engineers and Engineer
First line manually records incident
support

Checks uptime or 0:
downtime
Checks for historical
of network devices through
Manual Database system data in manual
pings and traces
database

Troubleshoo
t
and fix the
problem Closes the
incident
Network Engineer

Figure 2 Context Diagram: Current system

In the diagram above the first line support team periodically checks the network
device status through manual pings and notifies the network engineers if the devices
are not reachable. An outage report with start time is recorded in a manual database
and immediately escalated to network engineers. The network engineer
troubleshoots, fixes the problem and records the end time of the outage, cause and
solution that was implemented to fix the fault. The network engineer is also
27 | P a g e
 lOMoARcPSD|26463657

responsible for updating the database if a device is added or removed.

28 | P a g e
 lOMoARcPSD|26463657

2.8.6 DFD of current system

Network Device Reques Network

Manual t Engineer
network
monitoring tool Response

Figure 3 DFD of current system

2.9 Weakness
 Maintenance of the system is very difficult.
 It relies heavily on manual checking which is not reliable.
 There is a chance for obtaining imperfect results.
 More time is taken in processing activities.

2.10 Evaluation of Alternatives

2.10.1 Outsourcing
Outsourcing is defined as the organizational practice of contracting for services from
an external entity while retaining control over assets and oversight of the services
being outsourced (National Academy Press, 2000).

Outsourcing companies or big agencies will typically ask business owners to sign
lengthy contractual agreements, and they will include plenty of fine print. If terms are
not carefully understood there are chances of getting hit with unexpected costs (C.H.
LOK, 2017).

Processes that are outsourced need to be managed to ensure there is diligence

system security. An example of this is outsourcing the IT function and having an
outsourced employee use their access to confidential customer data for their own
gain (Lotich, 2017).

Disadvantages of Outsourcing
 It is expensive.
 External solutions may not provide specified solutions to tackle organizational goals.
 High possibility of no access to the source code.
 Employees are trained to such an extent that there will be need to call them
again when problems occur.

29 | P a g e
 lOMoARcPSD|26463657

30 | P a g e
 lOMoARcPSD|26463657

2.10.2 Improvement of current system

 A manual monitoring system relies heavily on the actions of humans, which
increase the possibility of human missing some outages or taking long to
discover faults.
 Engineers might forget to record an outage and this will result in wrong statistics
and wrong decisions will be made. Automation is there for needed to eliminate
human errors.
 A manual system is labour intensive and complicated, there for need to get rid of it.
 It will also take more time trying to improve the manual system and still not
getting the benefits that comes with automation, hence no need to try and
improve the current system.
Yaba Tech SL is a company that aspires to be a leading brand in information and
technology must be able to dictate paces in as far technically breaking new grounds
if they are to achieve their goals. Looking at the global trends a manual monitoring
system is an ancient way of doing business that neither promotes reactiveness nor
efficiency and effectiveness hence Yaba Tech SL must not consider improving such
a system.

2.10.3 Development
Developing a software package proves to offer more benefits to the organization as
compared to outsourcing. The project has already proved feasible with the benefits
out weighing the costs. The company will certainly be able to proactively monitor
devices availability as well as having access to historical trends that are related to
network devices availability.

Benefits of Development
 It is less costly as it is being done by people who are already under the company
payroll. Costs incurred in development phase and maintenance stage are mostly
anticipated because of the feasibility study. Outsourcing on the other hand, will
see the company signing lengthy and costly contractual agreements.
 There will be less training costs as the system users will be involved in
development. On the other hand, outsourced systems require massive training
and, in most cases, not all details are disclosed as the developer would want
an organization to be dependent on them to attract more charges.
 It provides a platform for staff development and gaining experience resulting in
identifying traits held by staff members.

31 | P a g e
 lOMoARcPSD|26463657

Based on the feasibility study carried out in chapter 2, In house software

development proved to be very feasible.

Recommendations on Alternatives: From the alternatives given above the best

alternative will be to develop the software in house because there is need to develop
a system that suits the company requirements. It is also the most cost-effective
alternative since expenses like training and installation will not be incurred by the
company.

2.11 Requirements Analysis

This section looks at what capabilities should the new system provide for its users
that is functional and non-functional. It also looks at what data must be captured and
stored. It also looks at what performance level is expected as well as well as tasks
that requires priority. Requirements analysis can be divided into:
 Functional requirements.
 Non-functional requirements.

2.11.1 Functional Requirements

Sommerville (2004), states that functional requirements capture the proposed
behaviour of the system. Functional requirements are expressed either from the
system's viewpoint or from the viewpoint. From system’s point view, they describe
the tasks of the system in terms of the set of functions that the system shall provide.
From the user’s standpoint, they described the system tasks in terms of user
objectives that the system needs to satisfy during its execution.

The system shall:

Process Requirements
 Detect alerts, diagnose and record network devices statistics efficiently.
 Store all the information required in the system database.
 Allow network devices uptime statistics to be searched and viewed easily.
Interface Requirements
 Allow the users to use the application in which they access devices statistics.
 The user interface should be almost self-explanatory with clear buttons to
help guide users.
 The system should be user friendly.
Regulatory Requirements
 The database will provide all the details pertaining devices being monitored.

32 | P a g e
 lOMoARcPSD|26463657

Security Requirements
 The system will contain confidential information thus system users will have
access that is limited to their respective access level.
 The administrator will have access to all the functions of the system.
 Technical manager will have access to all reports.

McLaughlin, Pollice and West (2006), describe a case diagram as a structural

document representing the interaction between the user the system. It is a simple
tool for describing the behaviour of the system and involves a contextual description
of how the users are intended to deal with the proposed system.

2.11.2 Functional Requirements

Start

Monitoring
activity

Network Device
Monitoring reports
System

Start IP Gettin Stop Subnet Evaluation

Monitorin Address g Monitorin Mask
g Curren g Calculato
t r
sessio
n
33 | P a g e
 lOMoARcPSD|26463657

Figure 4 Case diagram

2.11.3 Non-Functional Requirements

These are requirements that clearly state the ways or strategies that can be
employed to assess the operations and functionality of the proposed system
(Wiegers and Jennifer, 2005). Non- functional requirements improve the flow of
information. Non-functional requirements involve:
 Reliability- the system to be used must perform constantly for it to be accepted.
 Security system Maintained- security of organizational information should be
maintained by the use of passwords and high security levels.
 Flexible and easy to operate- complex graphical interfaces can make the
system difficult to understand.
 Maintainability- the proposed system should be easier to maintain and scalable.

2.12 Conclusion
At this stage in system development, a detailed study and evaluation of the current
system was performed. Fact finding techniques such as interviews and observations
were adopted for obtaining information for the system. This study was aimed at
examining the system’s input, processes and output requirements of the current
system. Context diagram, Dataflow diagram and Activity diagram of the system
where further used to represent the flow of data. Use case diagrams were also used
to show the functionality requirements of the system. When done with the design
then it is needful to convert the design into machine-readable code and finally come
up with a deliverable product.

34 | P a g e
 lOMoARcPSD|26463657

35 | P a g e
 lOMoARcPSD|26463657

3. CHAPTER FOUR: SYSTEM DESIGN

3.1 INTRODUCTION
Having successfully gone through the existing system, and fully understood how it
operates the next step was to design the proposed system. This entails outlining the
procedures that will be taken to develop and configure the incoming system.
Generally, design gives an outline of the System design, Physical Design, System
Architecture, Database Design, Interface Design, Program Design and Test Design.

3.2 SYSTEM DESIGN

Physical Design
This was concerned with how the physical or hardware and network components of
the proposed system were going to be laid out and how they were going to be
communicating.

System Design: An overview of Functionalities

The essence of the project was to replace the manual network monitoring system
that has resulted in lack of proactive network monitoring. This overview was meant to
brainstorm all system functionalities so as to simplify the design of the system.

After project completion the following functionalities were offered by the system.
 Users were able to instantly detect datacentre devices outages and
immediately trigger sound alarms to alert engineers.
 Users were able to perform polling of devices statistics every minute and
generate red flags when the nodes are down.
 Users were able to provide periodic historical reports of devices uptime trends.

36 | P a g e
 lOMoARcPSD|26463657

Context Diagram

Figure 5 Context Diagram

DFD 1

Figure 6 DFD

37 | P a g e
 lOMoARcPSD|26463657

DFD 2

Start

Authenticatio
n

IP Subnet Calculator

Internet Network Calculation

Protocol Type

Figure 7 DFD
3.3 ARCHITECTURAL DESIGN

This is a distributed system model with a set of stand-alone clients (computers) that
access a central monitoring server for services. A network allows the client to access
the services so basically the system will be using a centralized database and
application programs on client computers.

Hardware Architecture
The hardware architecture shows network connectivity layout and various
applications servers that run on the hardware. The star topology is fibre based with a
central switch and two core routers.

38 | P a g e
 lOMoARcPSD|26463657

Figure 8 Hardware Architecture

39 | P a g e
 lOMoARcPSD|26463657

Software architecture
The essence is to show a diagram on how the major software components relate. It
does not present the programming facets.

Figure 9 Software Architecture

3.4 User Interface design

Interface Design
Dennis, Wixom and Roth (2012) defines user interface as a “part of the system with
which the users interact. It includes screen displays that provide navigation through
the system, the screens, forms that capture data and reports that the system
produces”. The Graphic User Interface (GUI) would be used as the communication
link between system users and the system. All the input to the system has to be
entered by the user through various pages that are presented when they log into
the system.

3.4.1 Menu Design

The screens are presented to users to communicate with the system. Application
instructions will have to be invoked by various buttons and menus with inserted code
to perform operations like:

40 | P a g e
 lOMoARcPSD|26463657

Figure 10 Main dashboard

3.4.2 Input Design

Figure 11 Main dashboard

Figure 12 User creation menus

41 | P a g e
 lOMoARcPSD|26463657

3.4.3 Output Design

Figure 13 List of devices

Figure 14 Device status

3.5 PROCESS DESIGN

Process design represented the processes of the system. The flow chart below is
an illustration of how processes like a user password are verified until one is forced
out of the system if he or she gives a wrong password for at least three attempts.

42 | P a g e
 lOMoARcPSD|26463657

Figure 15 Process Design Flow Chart

3.6 PROGRAM DESIGN

Contain details concerning the new system’s programs. It is a component of design
phase of the Development life cycle. The tools used include class diagrams,
sequences, collaborations and packages.

43 | P a g e
 lOMoARcPSD|26463657

3.6.1 Class Diagram

Class diagram is a type of an inactive structure illustration that describes the
structure of a system by presenting the system's classes, its attributes, methods and
the relationships among objects and it can also be defined as a Unified Modelling
Language (UML) based communication tool.

Session
Network services

-Toolname:
-Tool version: String
Monitor -Active: boolen
s

Periodic OnDemand
-Start: date
-PublicKey: String
-Period: time
-miniLatency: time
-Priority: Interger

Figure 16 Class Diagram

3.6.2 Sequence Diagram

The sequence diagram is an arrangement of messages between instances (objects) of a
class, components and actors.

44 | P a g e
 lOMoARcPSD|26463657

Polling node Monitoring server User

Gateway

Login and
Polling
Authentication
Node/network
Polling data
Data aggregation
State request
Forwarding Node/Network
Aggregated
data State response
Polling data
Protocol translation
Display node / Network state

Polling data

Update node State

Pushing node
State
Network state

Collaboration

Users
1.Receives alert (Category, Activity)
Monitoring tool

Users
(Category,
Activity)

2. Outage stats
recorded Database

3. Incident record retrieved

4. Incident report
generated

Record Report

45 | P a g e
 lOMoARcPSD|26463657

Figure 18 Collaboration Diagram

3.6.3 Pseudocode

// Login to server monitor

If user's username and password exists and user is
activated return "servers status and program menu"
else
exit program
// Server statuses
select all servers
initialize server
status
while server status is off
display red color and notify with
sound add to logs
if server status change
is 1 disable sound
else if status is on
display green color and disable
sound add to logs
else
display red color and notify with
sound end while
while server status is on
display green color and notify with
sound add to logs
if server status is off
display red color and notify with
sound add to logs
else
display green
color end while
//Add new server to
monitoring if servers menu
is selected
return all monitored
servers if add new is
46 | P a g e
 lOMoARcPSD|26463657

selected
input server
name input
server ip
input server type
input server
description add
server to database
if edit is selected and user is
admin change server details
if delete is selected and user is
admin delete selected user
if history is selected and user is
admin show graphs
//Add new users to
monitoring else if users
menu is selected
return all users

if add new is
selected input
user name input
name
input user level
input user
password add
user to database
if edit is selected and user is
admin change user details
if delete is selected and user is
admin delete selected user
// view status logs
else if logs menu is
selected return all
status logs
// view config page
else if config menu is selected
set email and page refreshing settings
47 | P a g e
 lOMoARcPSD|26463657

// view config page

else if logout menu is
selected exit system

3.7 DATABASE DESIGN

The database design is also referred to as the data model. This is normally
represented in three levels namely the external view, conceptual model and the
physical model. This was significantly useful in representing the different database
mappings that could be Utilise in the implementation of the database which was
done in chapter five.

Figure 19 Entity Relationship diagram

This is the visualisation of entities and its relationship to other entities. There as
entities such as person and suspect. The entities have attributes.

48 | P a g e
 lOMoARcPSD|26463657

49 | P a g e
 lOMoARcPSD|26463657

Time stamp
Outage ID

Polling
Logged

Outage

Alerts Involved in

Sound
User
Record
Status Name Password

Device Email

Figure 20 Enhanced Entity Relationship diagram

Table 5 Session

Entity Attribute Description Data Nulls Multi-

value
type and d
length
Outage Time stamp Period of Date (12) No No
outage
incident
Polling Checking availability. Boolen (5) No No
Logged Outage recorded Number (15) No No
Outage ID Primary key uniquely Number (7) No No
identifies outage

50 | P a g e
 lOMoARcPSD|26463657

Table 6 Device information

Entity Attributes Description Data Null Multi-

value
type d
length
Sound Device Device name, primary 10 No NO
key
Status Device outage status 5 No No
Record Historical 13 No No

outage information

Table 7 User information

Entity Attributes Description Data Null Multi-

value
type d
length
User Name User login name, 9 No No
Email User email address 12 No No
Password User login password 13 No No

3.8 SECURITY DESIGN

It is difficult to effectively create a defense-in-depth security posture without the

knowledge of what is being protected and how it needs to be protected. The essence
of the subordinate security design topic brings out how the security baseline.

Table 8 Security Design

Issue Threats Protection

Input Data Incorrect Data validation

Output Data Unauthorized access, theft Passwords, Firewalls

Hardware Equipment Power surges and UPS

blackouts

Software Malware Malware sniffers

and Detectors

51 | P a g e
 lOMoARcPSD|26463657

3.9 BACKUP DESIGN

Backup software Server will be used. The operation of the system is 24/7 so there
are no off hours. Thus there is very little or even non-existent backup window. In a
bid to operate within the backup window differential backup is employed. Hardware
and infrastructure upgrades are vigorously pursued. Also the exponential
modification of the network backup design using server-free backup is a priority. For
the servers, in addition to the daily scheduled backups of data, a full backup is done
before every major update so that its entire hard drive can be restored.

3.9.1 Onsite backup

 Data is copied to an external hard drive.
 One backup copy (replica) is made.
 Data is stored as a Binary Large Object (Blob)

3.9.2 Offsite backup

 Outage records are automatically sent to a remote centre.
 One backup copy (replica) is made and stored offsite. The Grandfather-Father-
Son generation backup scheme is a priority.
 Redundancy Array of Discs is also going to be employed.

3.10 TEST DATA DESIGN

This is a design that is planned in advance to determine what is going to be tested
and the collection of data to be tested. Test data is related to the systems analysis
stage but the design is done in the designing phase. The test cases are presented
as illustrated screenshots in the annexure of the implementation phase which is
chapter five together with the expected or unexpected results.

3.11 DEPLOYMENT DESIGN

The design stage was meant to illustrate how software elements, objects and
processes would be deployed into the physical architecture of the new system. This
also illustrates the configuration of the hardware units, for example computers and
communicating devices and how the software components are going to be
distributed across the new system’s platform.

3.12 Conclusion
When done with the design then it is needful to convert the design into machine-
readable code and finally come up with a deliverable product. The design phase
demarcated the operation of the system in the actual physical environment and it
offers the stipulations of the constituents of the software that are to be developed in

52 | P a g e
 lOMoARcPSD|26463657

detail. With the hardware and software requirements have been designated, which
will be used in conjunction with the system, and then the desired system can be
designed. The system has been designed in a manner that provides maintainability,
efficiency, reliability and relative cost reduction.

53 | P a g e
 lOMoARcPSD|26463657

4. CHAPTER FIVE: IMPLEMENTATION/ CONCLUSIONS

4.1 Introduction

The chapter illustrates the implementation of the proposed system based on the
analysis and design presented in the previous chapters. Implementation entails the
translation of the solution model into source code. This means applying the
characteristics, methods of each object and integrating all the system modules of the
system that were stated in the previous chapters. System testing is also done at this
stage; during this stage the loopholes in the system are also identified. After all has
been done then the system moves on to the stage were the system is installed which
is known as the installation phase.

4.2 System Specifications

De Marco T, (1979) defines system specification as a detailed description of the

tasks required of a new system and includes all the details necessary to implement
the system and to understand the whole working of the system. The specifications
helped in identifying the areas that needed to be adjusted to meet the customers’
needs. The specifications were done under two sub-topics software and hardware
specifications. These reflected how the actual applications would be handled by the
system.

4.2.1 Software Specifications

The essence of discussing these specifications is to bring out the programming or

logical implementation of the system. It delved on platforms, packages and the
Dynamic Link Libraries (DLL).

5.2.1.1 Platforms
This encompasses Graphical User Interface (GIU) builders, compliers and class
libraries that were used to develop the system applications. The following are issues
covered under this caption:
 It was developed to run on any Microsoft Windows platform but can be integrated
on other platforms.
 It is coded using PHP with the implementation of already made objects
(interfaces) as well as inheritance from base classes such as Persons.

54 | P a g e
 lOMoARcPSD|26463657

55 | P a g e
 lOMoARcPSD|26463657

5.2.1.2 Packages

These provided organization of the program.

 The system has three namespaces namely Data, Entities and Interface.
 The objects are in various containers derived from the database entities.

5.2.1.3 Libraries

 Data library for dynamically creating database.

 Entities Library for the system object model.
 Implementation library for implementing the objects.

4.2.2 Hardware specifications

Hardware specifications refer to the physical gadgets where the system is going to
reside and run. Types of servers and computers to be used should be known
in advance as some software are not compatible with 64-bit-operating systems
while others works well with 32- bit-operating system. Hardware specifications are
tabulated below: -

56 | P a g e
 lOMoARcPSD|26463657

Table 9 Hardware Specifications

Type Description Minimum Maximum

requireme Requireme
nts nts
Client Desktop (Dell) HDD 500GIG 1TB
RAM 4GB 8GB
Processor Speed 533MHz 2400Mhz
Processor type Corei5 Corei7
Network Cards 10/100 10/1000
DVDROM 56X
Server (HP ML 150)
Processor Family Intel Xeon
Number of processors 1 2
Processor cores 6 12
Memory 12GB 256GB
Memory Slots 2DIMM 16DIMM
Memory type DDR3 DDR4
SFF/LFF/SAS/SATA 4TB 32 TB
Network Ports (1GbE) 1 2
Routers Cisco IOS Operating
System
(Cisco ASR1004) Racks 1U 2U
Throughput 1Gbps 2Gbps
Service Module Slots 2 4
GigabitEthernet10/100/1000 1 3
-
TX
CPUs 1 3
Switches (Cisco Ports 8 24
C4948)

4.3 Testing

Testing plan is the actual testing methods of the purposefulness of the new system
basing on the user requirements documents. Test schedule is necessary in system
development in the sense that it details the process of testing the systems’
functionality as well as showing steps taken to achieve certain results. It also
highlights the anticipated resources, personnel involved, risks coupled with the test
and the to-do list of the testing activities.

4.3.1 Test Data Results

Validation is defined as the revelation that the new system implements each of the
user requirements correctly and completely thus the right product was built. The
validation exercise was carried out by the validation team formed from members of
the technical department. The team was armed with a validation project plan
57 | P a g e
 lOMoARcPSD|26463657

detailing risk assessments,

58 | P a g e
 lOMoARcPSD|26463657

system development specifications (user requirements and functional requirements)

and documentation guide for installation of hardware and software. This was
deliberately intended to ensure that the system did not transgress from the
expectations as encapsulated by the user requirements.

Figure 21 Incorrect service type

Figure 22 Wrong IP address details

Verification

Verification is proof obtained after examining the system processes that specified
requirements have been fulfilled. Software verification is a corroboration that the
output of a particular module of system or subsystem meets all of the input
requirements for that system or subsystem thus the software product was built right.
In this regard the system was verified by using test data. The test data was a
combination of expected (correct) and incorrect data.

59 | P a g e
 lOMoARcPSD|26463657

4.4 Installation and Conversion

After the system was fully tested it was time for the transition phase. But before the
process was carried out an informed consideration of various choices was to be
made. This was done after a substantial analysis of different conversion styles. Each
is discussed bringing out why it was accepted or rejected.

There were some factors that aided in reaching the decision. The factors included:
 Conversion style meant the movement from an old manual detention system to
the newly developed system that could be adopted either progressively or
instantaneously.
 Conversion module referred to the scenario where the new system could be
introduced in bits and pieces, thus module by module.

Direct changeover

This is the plunging into the new system. With this method dates of migrating from
the new system would have been announced and the old system abruptly cut-off.
This was not considered due to high risk factors.

Advantages
 It consumes little time and energy
 economical in terms of cost
 Less complex if no problems are experienced.

Disadvantages
 Risks involved in adopting this method were relatively high as it could be very
difficult to recover and return to the old system if the
new system had failed.

Phased Changeover
In this method users would have been shifted to the new system province by
province. When one province is up and the system is running without hiccups, the
shift is to another province. This was to be repeated until all Provinces were
connected. This method was not approved.

Advantages
 Less overwhelming work all at once.
 Experience gained in connecting one province would have facilitated the

60 | P a g e
 lOMoARcPSD|26463657

efficient changeover of subsequent provinces.

 It would have allowed system development to be conducted in phases and risks

spread over a long period of time.

Parallel run changeover

This method was considered most appropriate and was used. Both systems were
run concurrently using the same inputs and outputs which were crosschecked and
differences resolved. After it was proved that the new system is working well the old
system was shut down.

Advantages
 Parallel run changeover facilitated the testing of the new system while retaining
the existing one, thus if the new system does not satisfy the organisation’s
strategic goals it is easy to revert back to the old system.
 Output could be reconciled.

Disadvantages
 The method is costly because of duplication involved of both additional
manpower and other material resources.

Pilot Changeover
With this method the new system would have been first introduced in Harare
Province. Same characteristics of the system were to be setup, run, tested for
functionality and then gradually introduced throughout the rest of the organisation
using any of the changeover methods. Pilot changeover would have enabled the
testing of a system on a smaller-scale in order to avoid possible resource wastage
should a system be found to be undesirable. This was again not considered.

Disadvantages
 A very slow method of system changeover.

Other Factors considered in choosing the best strategy

The following factors were augmented and strengthened the selection criteria of the
solution to migrate to the new system.
Risk factor
When a new system is introduced, there are chances of risks impeding the project.
Risks can be in many forms such as technological risks, problems and errors
(system bugs) and manmade risks (resistance to change). Humans are prone to
errors, undiscovered system errors during testing period can be flushed out during
conversion. Direct conversion was considered very risky as compared to both
parallel conversion and pilot changeover methods.
61 | P a g e
 lOMoARcPSD|26463657

Cost factor
Cost is another important factor taken into consideration before selecting the
conversion method because some methods require additional staff or material.
Direct conversion is more costly as compared to parallel cutover method whereas
pilot changeover costs are significantly higher when compared to direct changeover

Time factor
Time factor entails the time taken to migrate from the outgoing system to the
incoming system. Direct changeover is the quickest but parallel was the most
efficient.

4.4.1 System training

Training is critical as it bridges the performance gap between what is expected and
the actual output. The system is not difficult to learn as it is a product driven from
legacy a manual system that were being used by the first line technical support and
engineers. They are fully conversant of the operational procedures of the monitoring
system. Their training was really easy. It was discernible and provided the least
challenge. The training was conducted by the developing team.

Training schedules

Table 10 Training Plan

Topic Target Group Duration

Introductions Commanders, Systems Administrators 25 mins
and users
System Overview Commanders, Systems Administrators 3 days
and users
System logging on and Commanders and System 15 mins
off Viewing of reports Administrator s 1 hour
s and
Commanders System
Administrators s
Analysis of reports Commanders and System 1 days
Administrators s
End user training (Theory) Frontline support 3 days
End User Training Frontline support 3
(practical)

62 | P a g e
 lOMoARcPSD|26463657

4.4.2 System installation and User Acceptance

System installation refers to migration from the old system to newly developed
system done by developers of the system. Before the transition from the legacy
system testing was done. At each stage the approval to the next stage was granted
by the management and users were involved but not all. After the coding few
functional and non-functional requirements could have been missed therefore it was
imperative to go back to the users.

4.5 Maintenance

Dennis, et al, (2012) defines system maintenance as the process of refining the
system to make sure it continues to meet business needs. In view of this system
there is a relentless need to ensure that the server and network is periodically
reviewed and where adjustments are they are done likewise. The initial
maintenance is carried out first using information gathered during post-
implementation. After the initial maintenance, periodic reviews and users requests if
done and received will call for system maintenance. When the system is aging, the
maintenance frequency will increase thus demanding for high budgets costs on
maintenance and the only way to address this problem is to undertake a new system
development.

4.5.1 Maintenance Strategies

5.5.1.1 Corrective maintenance

As the name suggests, it is a rectification of design, coding and implementation
errors that were not noticed during the testing phases. As these errors are critical,
urgency is needed to address them.

5.5.1.2 Adaptive maintenance

This type of maintenance is carried out to curtail changes brought about by the
external environment or new user requirements.

5.5.1.3 Preventative maintenance

Preventative maintenance is an ongoing periodic inspection of the system’s

hardware and software to detect defects which indicate or might indicate potential
problems in the near future. The defects should be attended in no time else if no

63 | P a g e
 lOMoARcPSD|26463657

preventative maintenance is carried out, in some point in time in the future whole
system will total breakdown.

4.6 Performance Analysis

Performance analysis is defined as an act of telling the performers what actually

happened as opposed to what they perceived to be happening. An information
system is introduced in an organization with the focal point of addressing certain
problems. What the system does when implemented will be analyzed with what it
was being anticipated to operate and there can be a variation in system
performance.

Throughput
This is the rate at which successful message delivery or packets are measured.
 The system has capability to measure latency of the connection.
 Reveals statistics of link quality every minute.

Speed
 The system is programmed to provide sound alerts if it does not get ping from
device responses within one minute
 The system is programmed to show red flags for any device if it does not
get ping responses within one minute.

Services
 The system detects data center devices outages and triggers sound alarms to
alert engineers.
 The system performs polling of devices statistics generate red flags when the
nodes are down.
 The system provides periodic historical reports of devices uptime trends.
 The system automatically measure latency, or the delayed transfer of data.
Security
 The system is role based.
 Passwords are required to access the system.
4.7 Recommendations
 System maintenance and training of the system users should continuously be carried
out.
 Strong usernames and passwords should be implemented to enable project

64 | P a g e
 lOMoARcPSD|26463657

system security.
 The system should be provided with a continuous backup for system
recovery for the event of system failure.
 An organization should enforce an information technology system policy to
protect system functionality as well as the company’s information.

4.8 Conclusion

This chapter looked at system implementation procedures and conversion methods

that should be used in making the system go live. Numerous factors were used to
reach an informed decision. Taking into account these factors the Yaba Tech SL
image is heightened through the holistic implementation of the system. Above all
strategic goals would be achieved. With this in mind numerous activities were
discussed in this chapter. These include system specifications, testing plans,
installation and conversion plan, maintenance, performance analysis, and testing
techniques. All these were in preparation of the actual installation and conversion.
The next chapter is the results and discussion.

65 | P a g e
 lOMoARcPSD|26463657

Reference list
Dennis, et al, (2012), Systems Analysis and Design

De Marco T, (1979), Structured Analysis and System Specification

Dennis, Mox and Roth (2012) Denis, A. and Wixom B.H, (1999) System
Analysis and Design, 1st Edition, Prentice Hall, London (Britain).

Gillharm, B. (2002), Real World Research: Oxford: University press

Kvale, M. (1996), Introduction to Qualitative Research. London: Prentice Hall
McLaughlin, B., Pollice, G., West, D. (2006). Head First Object Oriented Analysis
and Design, O'Reilly Media.

Somerville. G. (2008), Software Engineering. India: Dorling Kindersley

Taylor-Powell .E and Steele .S, (1996), Program Development and Evolution,

Collecting. https://www.dandemutande.co.zw (Accessed on 11/10/2018)

66 | P a g e
 lOMoARcPSD|26463657

67 | P a g e
 lOMoARcPSD|26463657

Appendix A: User Manual

The user manual is created to simplify the navigation or use of the system by users,
so it was prepared to provide guidance to the user in the absence of the helpdesk on
how to operate the system. This manual has been designed to assist to assist the
users to get started with this new invention.

To access the site, open the browser and type 127.0.0.1/server and this will direct
you to the system Login page below:

How to login
Valid user login credentials will permit accessibility to the system resources
otherwise an error message will be displayed.

Insert system login

password

Insert System login password

Press login to access the system

Figure 23 A: Login menu

68 | P a g e
 lOMoARcPSD|26463657

Upon successful log in, the extension officer is directed to the page below which
shows devices status

Click on status to view network devices uptime

statistics

Green flags indicate that the network device is

down

Red flags indicate that the network device is down

Figure 24 A2: system device status dashboard

69 | P a g e
 lOMoARcPSD|26463657

To view historical device up time statistics

Figure 25 A3: Device viewing

Step1: Click on device you want to view

Step 2: It will lead you to figure below.

To view Hourly device up time statistics click as highlighted below hour and it will
display output as below.

Blue line displaying hourly latency statistics

Hourly uptime percentage

Figure 26 A 4: Hourly device uptime statistics

Click hour to view hourly statistics

70 | P a g e
 lOMoARcPSD|26463657

To view daily statistics click Day as highlighted below

71 | P a g e
 lOMoARcPSD|26463657

Blue colour indicates daily uptime and latency of the link

Figure 27 A 5: Daily device uptime statistics

Click Daily to view daily device statistics

Red colour shows daily device down time

statistics

The below diagram shows weekly device uptime statistics

Reveals that the device was Reveals that the device was
up down

Figure 28 A 6: Weekly device uptime statistics

Shows device weekly uptime percentage

Shows device weekly average

latency

Click here to show weekly device uptime

statistics

72 | P a g e
 lOMoARcPSD|26463657

73 | P a g e
 lOMoARcPSD|26463657

To add new devices on the monitoring tool, Step 1: click add new under
servers as shown below

Click update if changes have been

Figure 29 New device done to existing devices
addition

74 | P a g e
 lOMoARcPSD|26463657

Step 2: Insert device details s text boxes as shown below and press save to finish

Enter details on text boxes

Click drop down menus to choose options

Figure 30 A 7: New device addition menu

Click save button to finish

Select user permission under this option

75 | P a g e
 lOMoARcPSD|26463657

Figure 31 A9: Device list

List of monitored servers Option to modify
devices

To add users click on users under main menu as shown below

Next step click add new as shown

below Click users

Click add users

Figure 32 A 10: User addition

76 | P a g e
 lOMoARcPSD|26463657

Enter user details on text boxes

Choose user privileges Administrator

or User

Select servers to be viewed

Figure 33 A 11: User addition Menu

Click save button to complete the
process

77 | P a g e
 lOMoARcPSD|26463657

78 | P a g e