SYSTEM IMPLEMENTATION,
TESTING AND VALIDATION REPORT FOR
ENTERPRISE DATA
TRACKING SYSTEM (EDT)
CHAPTER ONE
INTRODUCTION
This
section gives a scope description and overview of everything included in the
Software Design document. Also, the purpose for this document is described and
a list of abbreviations and definitions is provided.
1.1
BACKGROUND OF THE PROJECT
The
process of works monitoring in any Electricity Company is a tedious job. The
electricity company performs various works at various geological points.
Currently, for these works the company will be having the project manager, who
will be taking care of the various sites. The Project manager currently
furnishes only their weekly or monthly expenditure details and progress of
works; because of this the company has to wait, to know the expenditures and
the progress of work made by the various remote sites.
This
process is very much time consuming and it involves a lot of manual work to be carried
out. To update the day to day activities, every project manager has to interact
with his fore man, record all the information’s they have been doing at the
fields then he generates a report for this activities. To provide all these
facilities at the remote site the company has to spend huge sum of money, time,
and fuel. So to surmount this problem a new framework will be developed. The
project entitled “Enterprise Data Tracking Application that will run on tablet
devices that helps the employees communicate to each other easily based on the
employment level.” has been developed for the betterment of the Company. By
developing this application the Company can easily record their progress of
various works and their day to day expenditures that are made at various sites.
SCOPE
OF THE PROJECT
The
Enterprise Data Tracking System is mobile application that will run on table
devices that helps the employees communicate to each other easily based on the
employment level. The application should be free to download from either a
mobile phone application store or similar services.
Employees
can provide their company information using the tablet devices. This
information will act as the bases for the monitoring results displayed to the
managing director. The managing director also uses the application in order to
keep the information accurate. The managing director can, for instance, view
work progress done at various sites and give advice according to the user
information.
Furthermore,
the software needs both Internets to fetch and display results. All the information
is maintained in a database. The application is required to be installed on the
user’s tablet devices. The application also has the capability of recording the
progress of various works and the day to day expenditures that are made at
various sites and also representing both summary and detailed information about
the employees.
1.2
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS,
1.3
REFERENCES
[1] IEEE Software Engineering
Standards Committee, “IEEE Std 830-1998, IEEE Recommended Practice for Software
Requirements Specifications”, October 20, 1998.
[2] Feldt R,”re_lecture5b_100914”, unpublished.
[3] Davis M A, “Just Enough
Requirements Management: Where Software Development Meets
Marketing”, New York, Dorset House
Publishing, 2005.
[4] Karlsson J, “A Cost-Value
Approach for Prioritizing Requirements”, Norges Teknisk-
Naturvitenskapelige Uni. 1997
1.4
SYSTEM OVERVIEW
This document describes the
implementation, testing and validation findings for the An Enterprise Data
Tracking system. It is divided into the following sections:
Section 1: This section gives an
overview of the document
Section
2: This section describes and specifies the system completely and is the basis
for the validation process.
Section
3: This section provides the development
tools used to implement the system, notes on anomalies, module and integration
details.
Section
4: This section provides the inspection and testing of the computer system is
planned and documented.
Section
5: This section provides that the validation of the installation process
ensures that all system elements are properly installed in the host system and
that the user obtains a safe and complete installation, especially when
installing software products.
Section
6: This section provides the documentation of service and support concerning
maintenance, future updates, problem solutions, requested modifications
Section
7: Make a conclusion of your whole report.
CHAPTER TWO: SYSTEM SPECIFICATION
The user login into the system
using the password and username given to him/her by the IT Specialist and then
he navigates to the dashboard page where he can view tasks performed by various
stake holders, view the calendar, view the appointments.
The system then checks whether the
user who has logged in directing manager, if he is the one the system logs him
in and allows him to enter the details of the project won, view comments from
various stake holders, add comments and if the contract is won, the system
allows the project manager to implement the project. The project manager first
requests the procurement manager to supply him with a certain list of
materials, the procurement officer sends it directly to the managing director
to approve it, the procurement officer then writes a load instruction to allow
delivery of the requested materials, the project manager then then receives the
materials with delivery note showing the items he/she had requested for, The
project manager then approves the delivery note and sends the materials to the
fore man who will use the materials in the field.
The project manager then writes a
report of his activities done at the field. The foreman also prepares a time
sheet for the activities done at the field. The Fore man also writes down the
attendance of workers for easy payment.
2.1
VERSION OF THE REQUIREMENTS AND VERSION CONTROL
2.2
INPUTS
Input 1
The IT Specialist registers the
users and gives various users accounts. Registration involves inputting
username, password, email.
Logging in involves inputting
username and password.
Input 2
The system accepts inputs entered by the
user in form of material requisition.
Feature: Project manager –
Inputting material requisition fields
Scenario:
Required information for material requisition
Given
the Project manager wants to send a request form to procurement manager. The
inputs include.
Employee
name, date, material, quantity, unit cost and extended cost
Then
the project manager should be able to send the request form.
Input 3
The system accepts inputs entered by the
user in form of operation cost.
Feature: Project manager –
Inputting operation cost.
Scenario:
Required information for operation cost.
Given
the Project manager wants to enter operation cost. The inputs include.
Employee
name, Payroll type, payroll, description of work.
Then
the project manager should be able to generate operation cost.
Response to illegal inputs:
Please
enter figures
Input 4
The system accepts inputs entered by the
user in form of operation cost.
Feature: Project manager – Inputting
Fleet condition
Scenario:
Required information for fleet condition
Given
the Project manager wants to enter fleet condition. The inputs include.
Employee
name, company, vehicle condition, vehicle number.
Then
the project manager should be able to check fleet condition.
Response to illegal inputs:
Please
enter all fills.
Input 5
The system accepts inputs entered
by the user in form of appointment or meetings.
Feature:
Project manager – Inputting appointments
Scenario:
Required information for appointments.
Given
the Project manager wants to enter an appointment to meet other employees. The
inputs include.
topic,
place, date, members.
Then
the project manager should be able to create appointments meeting.
Response
to illegal inputs:
Please
enter all fills.
Input 6
The system accepts inputs entered
by the user in form of attendance list.
Feature:
Field supervisor – attendance list
Scenario:
Required information for attendance list.
Given
the Field supervisor or Foreman wants to enter an attendance of employees. The
inputs include.
Employee
name, date.
Then
the Foreman should be able to create an attendance list.
Response
to illegal inputs:
Please
enter all fills.
Input 7
The system accepts inputs entered
by the user in form of time sheet.
Feature:
Field supervisor – a time sheet
Scenario:
Required information for a time sheet.
Given
the Field supervisor or Foreman wants to enter a time sheet form. The inputs
include.
Employee
name, days worked, situation occurrences, total days
Then
the Foreman should be able to create a time sheet.
Response
to illegal inputs:
Please
enter all fills.
Input 8
The system accepts inputs entered
by the user in form of attendance list.
Feature:
Field supervisor – materials
Scenario:
Required information for materials.
Given
the Field supervisor or Foreman wants to enter remaining materials after field
activities. The inputs include.
Item
number, Item name, Item description.
Then
the Foreman should be able to create an material report.
Response
to illegal inputs:
Please
enter all fills.
Input 9
The system accepts inputs entered
by the user in form of photo description text.
Feature:
Field supervisor – photo description
Scenario:
Required information for photo description.
Given
the Field supervisor or Foreman wants to enter remaining materials after field
activities. The inputs include.
Item
number, Item name, Item description.
Then
the Foreman should be able to create an material report.
Response
to illegal inputs:
Please
enter all fills.
Input 10
The system accepts inputs entered by the
user in form of attendance list.
Feature: Procurement manager –
deliver note
Scenario:
Required information for Delivery note.
Given
the procurement manager wants to form a delivery note for materials. The inputs
include.
Item
number, Item name, Item description, unit, quantity, senders name, receivers
name.
Then
the procurement manager should be able to create a delivery note.
Response to illegal inputs:
Please
enter all fills.
2.4
FUNCTIONAL REQUIREMENTS
This
section includes the requirements that specify all the fundamental actions of
the software system.
2.4.1 User class 1 – The User
2.4.1.1 Functional requirement 1.1
ID:
FR1
TITLE: Download mobile application
DESC: A user should be able to
download the mobile tablet application through either an application store or
similar service on the mobile tablet device. The application should be free to
download.
RAT: In order for a user to
download the mobile application.
DEP: None
2.4.1.2 Functional requirement 1.2
ID:
FR2
TITLE: Download and notify users of
new releases
DESC: When a new/updated version or
release of the software is released, the user should check for these manually.
The download of the new release should be done through the tablet device in the
same way as downloading the mobile application.
RAT: In order for a user to
download a new/updated release.
DEP: FR1
2.4.1.3 Functional requirement 1.3
ID:
FR3
TITLE: User registration - Mobile tablet
application
DESC: Given that a user has
downloaded the mobile application, then the user should be able to get registered
through the mobile application. The user must provide Full names, user-name,
password and e-mail address.
RAT: In order for a user to
register on the mobile application.
DEP: FR1
2.4.1.4 Functional requirement 1.4
ID:
FR4
TITLE: User log-in - Mobile
application
DESC: Given that a user has registered,
then the user should be able to log in to the mobile application using username
and password given to him by IT Specialist.
The log-in information will be
stored in the tablet device and in the future the user should be logged in automatically.
RAT: In order for a user to
register on the mobile application.
DEP: FR1, FR3
2.4.1.5 Functional requirement 1.5
ID:
FR5
TITLE: Retrieve password
DESC: Given that a user has
registered, then the user should be able to retrieve his/her password by contacting
an IT Specialist.
RAT: In order for a user to
retrieve his/her password.
DEP:
FR1
2.4.1.6 Functional requirement 1.6
ID:
FR6
TITLE: Mobile application - tasks
DESC: Given that a user is logged
in to the mobile application, then the first page that is shown should be the
home page. The user should be able to view various tasks performed by the
various stake holders of the company. The project manager should be able to
view particular contracts that the company has won and they should be given a particular
contract to manage. A procurement officer should be able to select the
suppliers that are willing to supply various materials for project
implementation. The manager should be able to add comments on field activities.
RAT: In order for a user to view tasks
for various stake holders.
DEP:
FR4
2.4.6 User class 6 – The CEO
2.4.6.1 Functional requirement 6.1
ID:
FR24
TITLE: Mobile application – make Advice.
DESC: Given that a CEO has logged
in to the application, the CEO should be able to advice various stake holders
on their performances at various sites and activities performed.
RAT: In order to advice
stake holders on their activities performed.
DEP:
FR4
2.4.6.2 Functional requirement 6.2
ID:
FR25
TITLE: Mobile application – write Comment.
DESC: Given that a CEO has logged
in to the application, the CEO should be able to write
Comment on the various works of the stake holders.
RAT: In order to write
comments.
DEP:
FR4
2.4.6.3 Functional requirement 6.3
ID:
FR26
TITLE: Mobile application – view Captured Image.
DESC: Given that a CEO has logged
in to the application, the CEO should be able to view
captured images on the various works at the remote sites.
RAT: In order to view
captured images.
DEP:
FR4
2.5 LIMITATIONS AND SAFETY
Mobile
Context: When using computer tablets applications the user is not tied to a
single location. They may also be interacting with nearby people, objects and
environmental elements which may distract their attention.
Connectivity:
Connectivity is often slow and unreliable on tablet devices. This will impact
the performance of tablet applications that utilize these features.
Small
Screen Size: In order to provide portability tablet devices contain relatively
limited screen size and so the amount of information that can be displayed is
limited.
Different
Display Resolution: The resolution of tablet devices is reduced from that of
desktop computers resulting in lower quality images.
Limited
Processing Capability and Power: In order to provide portability, tablet devices
often contain less processing capability and power. This will limit the type of
applications that are suitable for tablet devices.
Data
Entry Methods: The input methods available for tablet devices are different
from those for desktop computers and require a certain level of proficiency.
This problem increases the likelihood of erroneous input and decreases the rate
of data entry.
2.6
DEFAULT SETTINGS
By
default, when the system is first installed, it contains only one user who has
been given the (username and password) for security reasons, the password can
be changed through an IT Specialist name who assigns usernames and passwords to
users of the application, Then the user logs onto the dashboards in which he
can view various tasks performed in various departments and then he is
restricted to access certain modules if he/she is not given access to access
that module.
2.7
SPECIAL REQUIREMENTS
This
section contains all of the functional and quality requirements of the system.
It gives a detailed description of the system and all its features.
2.7.1 USER INTERFACES
A
first-time user of the mobile application should see the log-in page when
he/she opens the application, see Figure 1. If the user has not registered,
he/she should be able to do that on the IT Specialist page.
If
the user is not a first-time user, he/she should be able to see the Home page
directly when the application is opened, see Figure 2. Here the user chooses
what he/she wants to conduct.
Every user should access a homepage where they
can be able to view various tasks performed by various stakeholders, View
meeting days, View phone numbers of their customers and other organizations
2.7.3 SOFTWARE INTERFACES
The EDT application communicates with the
database in order to get the information about the Employees. The between the
database and the tablet application consists of reading and modifying the data operations.
2.7.4 COMMUNICATIONS INTERFACES
The communication between the different
parts of the system is important since they depend on each other. However, in
what way the communication is achieved is not important for the system and is therefore
handled by the underlying operating systems for both the tablet application and
the database
2.8
PERFORMANCE REQUIREMENTS
The requirements in this section provide
a detailed specification of the user interaction with the software and
measurements placed on the system performance
2.8.1 Prominent task feature
ID:
QR1
TITLE: Prominent task feature
DESC: The task feature should be
prominent and easy to find for the user.
RAT: In order to for a user to find
the task feature easily.
DEP: none
2.8.2 Usage of the task feature
ID:
QR2
TITLE: Prominent task feature
DESC: The task feature should be
prominent and easy to find for the user.
RAT: In order to for a user to find
the task feature easily.
DEP: none
2.8.3 Response time
ID:
QR3
TAG: ResponseTime
GIST: The fastness of the task
SCALE: The response time of a task
METER: Measurements obtained from
1000 tasks during testing.
MUST: No more than 2 seconds 100%
of the time.
WISH: No more than 1 second 100% of
the time.
2.8.4 System dependability
ID:
QR4
TAG: SystemDependability
GIST: The fault tolerance of the
system.
SCALE: If the system loses the connection to the
Internet the system gets some
strange input, the user should be
informed.
METER: Measurements obtained from
1000 hours of usage during testing.
MUST: 100% of the time.
CHAPTER THREE
3.0
DESIGN OUTPUT
3.1
IMPLEMENTATION (CODING AND COMPILATION)
Development tools used to implement the
system, notes on anomalies, module and integration details
3.1.1 Hard drive space
ID:
QR5
TAG: HardDriveSpace
GIST: Hard drive space.
SCALE: The application’s need of
hard drive space.
METER: MB.
MUST: No more than 20 MB.
PLAN: No more than 15 MB.
WISH: No more than 10 MB.
MB: DEFINED: Megabyte
3.1.2 Application memory usage
ID:
QR6
TAG: ApplicationMemoryUsage
GIST: The amount of Operate System
memory occupied by the application.
SCALE: MB.
METER: Observations done from the
performance log during testing
MUST: No more than 20 MB.
PLAN: No more than 16 MB
WISH: No more than 10 MB
Operate System: DEFINED: The
Android Operate System which the application is running on.
MB: DEFINED: Megabyte.
ID:
QR13
TAG: ProjectManagerLoginAccountSecurity
GIST: Security of accounts.
SCALE: If a project manager tries to log in to the application
with a non-existing account then the project manager should not be logged in.
The project manager should be notified about log-in failure.
METER: 1000 attempts to log-in with
a non-existing user account during testing.
MUST: 100% of the time.
ID:
QR14
TAG: ForemanLoginAccountSecurity
GIST: Security of accounts.
SCALE: If a Foreman tries to log in to the application
with a non-existing account then the Foreman should not be logged in. The
Foreman should be notified about log-in failure.
METER: 1000 attempts to log-in with
a non-existing user account during testing.
MUST: 100% of the time.
ID:
QR15
TAG: CEOLoginAccountSecurity
GIST: Security of accounts.
SCALE: If a CEO tries to log in to the application
with a non-existing account then the CEO should not be logged in. The CEO
should be notified about log-in failure.
METER: 1000 attempts to log-in with
a non-existing user account during testing.
MUST: 100% of the time.
ID:
QR16
TAG: UserCreateAccountSecurity
GIST: The security of creating
account for users of the system.
SCALE: If a user wants to create an account and the
desired user name is occupied, the user should be asked to choose a different user
name.
METER: Measurements obtained on
1000 hours of usage during testing.
MUST: 100% of the time.
3.3
DOCUMENTATION
The report document has been
developed out of the design document and the readers of this document are:
The software developers, the system
analysts, the Users, the programmers
CHAPTER FOUR: INSPECTION AND TESTING
4.1
Choice of prioritization method
In order to get a view of how to
divide the requirements into different releases and what requirements should be
included in which release, a prioritization of the requirements is needed. This
section discusses the choice of prioritization methods and gives a suggestion
of how the release plan for these requirements could look like [1].
When prioritizing the requirements
the ten most important ones were picked out first. This was done with a simple
“1 to 10” ranking method, with one being “not important” and ten “very
important”. Based on the elicitation meetings, and the perceived ideas of what
was important to the different stakeholders, a number was set for each
requirement. The numbers were then summed up for each requirement and the ten
with the highest score were chosen to be prioritized with the cost value
approach. The results, which are red-marked, can be seen in Appendix I and as
shown, it turned out to be five functional requirements and five quality
requirements. These requirements were then prioritized according to the cost
value approach and the results can be viewed under Appendix II [2].
The remaining requirements were
prioritized according to the “Five-Way Priority Scheme” as shown in Appendix
III. This method was chosen since it gives the different stakeholders the same
importance and has an enough wide range for determining which requirement is
more important than the other [3].
However, in this prioritization
process, the development team was not included as a stakeholder since the different
features were not considered to be as important to them as for the other
stakeholders. Other methods for
prioritization, such as the hundred-dollar test and the yes-no vote, were also considered.
The hundred-dollar test is quite similar to the five-way priority scheme, since
it also gives a wide range for ranking the requirements. However, it is more
easily misused since someone could save all their money and put them on a
requirement that they think is very important [4]. Others might not agree that
this requirement is important but it might still get the most votes since one
person cared about
The
yes-no vote method might be fairly simple to carry out, however the range is
too narrow. For
instance,
if two requirements are not very important it would be hard to determine which
of those requirements that is more important than the other [4].
In
conclusion, weighing the disadvantages and advantages of these methods against
each other lead us to choose the five-way priority scheme.
Appendix
I: Selection for Cost-Value Approach
Table 2 – Select of ten
most important requirements
CHAPTER FIVE: INSTALLATION AND SYSTEM ACCEPTANCE
TEST
5.1
Input files
DBK
files
HEX
files
PWI
files
Plg
files
BAK
files
Opt
files
C
files
5.2
Supplementary files
The
application will be obtained from Google place store on your tablet, tap the
play store icon to open the store. The main page in the store will offer you
access to various applications then you can be able to search for this
application and download it by tapping the button on top.
NO
USER MANUAL
CHAPTER SIX
6.0
Performance, servicing, maintenance, and phase out
6.1
Service and maintenance
Maintenance phase deals with fixing
the issues that were fronted by the mobile users and also involve development/
releasing new features, which can be implemented using mobile application
development life cycle. Integrating new requirements in the use cases,
projecting, developing and finally testing improves the overall caliber of the
application when a systematic procedure is being implemented
Finding and fixing issues.
Make sure developer monitors the
ene to end performance of the application and understand where issues are
occurring before they become major problem for users. Don’t wait for bad
reviews and low ratings to find that your application is having functional
issues.
Communicate with users.
Let the users know what you are
doing and why and most importantly, why everything you do is aimed at making
their experience better and rewarding.
Production consideration: crash and
error reporting.
Chash and error reporting is a
requirement not only for the development of your application but also for testing
and production. There are quite few crash reporting tools available like
BugSense and TestFlight are capable of reporting fatal errors in an
application.
Production consideration: Analytics
and instrumentation
Smart executives are data driven
and mobile application can be a plethora of business intelligence
CHAPTER 7: CONCLUSION AND RECOMMENDATIONS
The
report includes requirements analysis framework which were used for analyzing
requirements used to implement a system. It describes the process with steps
starting with a vague description of a scenario, and then detailing the
scenario description through definition of roles and tasks. These tasks are
then analyzed using Cost-Value Approach.
Although
the framework has been tested against real-world scenarios, and it has been
implemented. The works
included
validating the framework within mobile software system design and testing it as
well.
and
finally performing a performance maintenance and phase out.
No comments:
Post a Comment