FYP Proposal

COMPUTING LABS INVENTORY

MANAGEMENT SYSTEM
FYP Proposal Number
CS-FYP-2018

Date of Submission
22nd-Nov-2018

Muhammad Hamza Siddiqui

BSCS/S15/0141

Arbab Muhammad Riaz

BSCS/F15/0153

SALMAN AHMAD
BSCS/S15/0106

Supervisor
Sir Iqbal Uddin Khan

Department of Computing
Faculty of Engineering Sciences & Technology
Hamdard University
 FYP Proposal

Table of Contents
1.0- Introduction
1.1- Problem Statement
1.2 Motivation
1.3 FYP Objectives
1.4 Literature Review

2.0 Project Scope

2.1 Scope
2.1.1 Design Goals
2.1.2 High level Requirement
2.1.3 Front End
2.2 Back End
2.3 Design Goals
2.4 Exclusion from Scope
2.5 Assumptions

3.0 Methodology
3.1 Project Approach (Agile)
3.2 Team Role & responsibilities (RACI matrix)
3.3 Requirement Development
3.4 Architect / Design
3.5 Development / Construction
3.6 Application (or Project) Testing

4.0 Project Planning

4.1 Gantt Chart
4.2 Mention following milestones in your Plan

5.0 Project Requirements

5.1 Software tools requirements
5.2 Hardware requirements

6.0 Budget/Costing
7.0 Project Deliverables
7.1 Milestone Plan
8.0 Reference
 FYP Proposal

1.0 Introduction
1.1 Problem Statement
It is difficult for the Head of computer labs to supervise each and every Computer lab at
certain time. Also that LABS head has no idea about where peripherals are connected to a
system. It makes difficult to monitor several systems throughout all labs. We want all the
information under a single hood to make information manageable.

1.2 Motivation
As this project is based on computer monitoring so this project can be used in any
university, firms and software houses.

1.3 FYP Objectives

To deliver a complete system monitoring application that works in real-time. The server
application should show a list of all the systems whether they are on/off (after one-time
connection). Clicking on a single system (unique serial number) which shows the CPU system
details, memory details, network, and disk information. Meanwhile, the client application
will keep on running in the background.
 FYP Proposal

1.4 Literature Review

A. Related work
1. Describe a software and hardware design solution of an embedded web-based remote
monitoring system for the environment in the laboratories. Build an embedded web server to
publish the data of sensor networks and video images to achieve remote monitoring which is
based on B / S architecture. Managers can control the equipments in the lab through a web
browser which is cross-platform. The embedded database manages the data collected by sensor
networks, realizing the local management of environmental data. The experimental results show
that the system designed implements safe and convenient remote monitoring and local
management of the environment in laboratories and has high availability, reliability and
popularization.

Reference : (https://dl.acm.org/citation.cfm?id=1913636)

2.0 Project Scope

2.1 Scope
The scope of the product is knowing every relevant information about a system’s hardware
so that we can cast it to an administrator-side application, so he may fully monitor it in real-
time. The client process will be running as a background process, while the server be
fetching information updates when a new client is turned on, or an existing one has turned
off.
The project stakeholders (primary) are the administrator(s) who want to monitor the
project.
The constraints are that we are heavily reliant on internet connectivity such that if it is down
at any time, we don’t know if a new system has been turned-on or an existing one has been
turned off.
At a later stage we want to make the program efficient by updating the elements
dynamically in the server application so that it doesn’t refresh the entire row on update.

2.1.1 Design Goals

The design goals are to develop a user-friendly application to view what a client system’s
current specifications are.
The design goals for the server application are to display clean information regarding all the
clients connected, which is easy to view for each system. It should clearly display which
system is currently active and which is not.
 FYP Proposal

Basic steps:

1. User will install the Desktop application of client.

2. User will install the Desktop application of server.

3. Client will send its system details to server through network.

4. Server will display the list of clients.

5. After clicking on any client from the list server will display its system details.

6. If Client shutdown the computer the server will not display the client in the

list.
 FYP Proposal

CLIENT APPLICATION:
Fetch hardware information.

SERVER APPLICATION:
Receives system details through network and display.

2.1.2 High level Requirement

The high-level requirement for this project is to display accurate hardware
information and broadcast it every time a client machine is turned on. And
additionally, it should also broadcast the time when the current client machine
was logged off.
The high-level requirement for the server application is to display all the
current logged on/off clients in real-time.

2.1.3 Front-End
Home Page (Client)
The home page of the client application shows the current system’s hardware
specifications, along with the login time.
Home Page (Server)
The home page of the server application shows the all of the system online
along with their login times, and logout times.

2.2 Backend
The backend uses a JavaScript library to fetch a current system’s hardware specifications.
The specs are stored in a mongo database, which stores specifications as a document, each
document identifiable by a UUID of the system, which will only be created once for every
single system. After that the record will be updated for each new login time/logout time.

2.3 Design Goals

User Features:
View System specifications
Server Features:
View all systems along with their specifications
 FYP Proposal

USE CASE 1: Admin wants to see the list of all the PCs
- Admin opens the server application
- Admin views the entire list of active/inactive PCs along with their timings

USE CASE 2: Admin wants to view a specific PC’s configuration

- The admin opens the server application where the list is appearing on the screen
- The admin navigates to the UUID of the system and clicks on it
- The above action opens a pop-up modal displaying a system’s configuration

2.4 Exclusions from scope

 FYP Proposal

- The following is a list of activities that are clearly excluded scope of development for
this proposal.
- Development of Detailed Functional Specification
- Detail functional specification is not included in this timeline. Scope document will
be the base document for the requirements.

2.5 Assumptions
Internet
We are assuming that to ensure accurate login/logout times of clients, internet connectivity
in the entire lab are active always.

3.0 Methodology

3.1 Project approach

We will use Iterative methodology. Reason being that we want our application to not break
while we scale it. Since the application’s itself is very simple, but due to the complexity of
the backend, we want to test the backend with the UI at every step to ensure that our code
works smoothly with the frontend. (fig. 1 below)
 FYP Proposal

Therefore, we first developed the backend for the client application, tested it with the
frontend, and then added real-time features on the backend to re-test it with the frontend.
We repeat the same steps for the Server application.
And finally, we wrap our entire code into Electron’s desktop application building tool, which
complies our JavaScript code into a Desktop application.
We then build the packager into an installer file which will allow the end user to
conveniently install the application in any system.
Tools and technologies used.

Backend:
Programming Language: JavaScript
JavaScript allows support for a large variety of libraries developed open source, which
allows a developer to build scalable and fault tolerant applications.

Database: MongoDB
We want the database to be scalable so that we can add/remove features or attributes from
the client’s application without using migrations (i.e. SQL databases), which would remove
the need to rollback the database each time a feature is added.

Frontend:
Templating Engine: Ejs
Ejs is a frontend templating engine that understands variables stored by the server which
were rendered to the page. Ejs is a widely used templating engine used for building simple
static applications involving database interactions.

Desktop Application: Electron

Electron-js is a desktop building tool in JavaScript which builds web-UI into desktop-UI. By
providing parameters like window width and height, and root file (typically main.js, which
stores the starting point of the app).

Installer Building: Electron-builder

Electron builder is a subsidiary product of electron-js which builds installer files for all OS
types (mac, linux, windows) in both x64 and x86 formats.
 FYP Proposal

3.2 Team role and responsibilities

Tasks Muhammad Arbab Salman Sir iqbaluddin

Hamza Siddiqui Muhammad Riaz Ahmed (Supervisor)

Problem R,A R,A R,A C, I

statement

Requirements R,A R,A R,A C, I

Design R,A R,A R,A C, I

Development R,A R,A R,A C, I

3.4 Architect/Design
The client system’s architecture is a library used in node-js coded on the backend to store
information relevant to a system’s hardware. The design is simply fetching this information
and displaying it on the front-end.
Similarly for the server application, the information regarding all the clients is fetched at the
backend from a mongo database hosted online (mlabs). This data is rendered to the
frontend in real-time
 FYP Proposal

3.5 Development/Construction
Used EJS (templating engine) to render the information coded at the backend to the front-end. Ejs
allows variables sent from the server to be rendered in a simpler fashion using a specific EJS syntax
(<% “variable name” %>). The library (system-information-npm) is used to fetch any system’s
hardware specifications.

We used ‘Pusher’, an online tool to develop real-time streaming databases. Which will be used to
broadcast each system’s login/logout time in real-time.

3.6 Testing
The project was initially tested by installing our client and server desktop application on the same
system. We ran the server application first which showed an empty list of 0 online systems. As soon
as the client application was run, the server application was refreshed, and it showed our current
system’s application on the server. The same behavior occurs when the client application was run on
different client machine.
 FYP Proposal

4.0 Project Planning

4.1 Gantt Chart

5.0 Project Requirements

5.1 Software Requirement
- The client system must have our hardware-application installed on the system

- The server which wants to know information about all the clients must have the server application
installed on the system

-MS office to view reports of the list of systems

5.2 Hardware Requirements

- Intel Pentium 4 or above
- At least 128MB of RAM
- At least 100 MB hard disk space
- Network Card for internet connectivity
 FYP Proposal

6.0 Budget/Costing
- Total cost of the project: Depends On Time
- Start Date: 19/11/2018
- End Date: 10/12/2019 (Expected)

7.0 Project Deliverables

1) Delivered a Client-side application (desktop) which displays CPU, network, memory, disk,
graphics, system information in a single window.
2) Delivered a Server-side application (desktop) which receives the broadcast sent by each
client and displays a list.
3) Software codes
4) User Manual
5) Mongo database

7.1 Milestone Plan:

1st Evaluation (Start of Next semester)
40% will be done in the end of this semester
1. Requirement elicitation
2. Graphical user interface
3. Design Database

2nd Evaluation (end of next Year)(expected)

100% work will be done in the end of next semester
All remaining work including report and fully functional Application.

8.0 References
Fig 1. (https://en.wikipedia.org/wiki/Iterative_and_incremental_development)
(https://dl.acm.org/citation.cfm?id=1913636)