Example Software Engineering Paperwork

Software Engineering : TDB 2163 2015
TDB 2163 SOFTWARE ENGINEERING

PROJECT DOCUMENTATION
LABORATORY AUTOMATION SYSTEM
Date: 14th August 2015
Members:
1. AFIQ AIMAN BIN ZAMRI
19071
2. MUHAMMAD NAZMI BIN MAT ASRI
19103
3. AMELIA ASYIQIN BINTI MOHAMAD
18856
4. KHALIDA ADEEBA BINTI MOHD ZAILAN 19271

5. WAN NOR SUHAILI BINTI WAN ZAHARI
19141
Page 0

OVERVIEW
This idea came up when we notice that there are quite some time it happened that the
laboratory door is not open and the students have to wait until the lecturer came because only
the lecturer or security department (control room) have the access to the door. This project is
to create a system for laboratory door as well light which can control the behaviour of those
particular appliances. The system can be controlled from a distance and the controller will be
included in the system as well. The controller is a web that will be associated with the
system and use Wi-Fi as connection medium. The concept that we are going to implement is
Internet of Things (IOT), which allow the specific user to have control over the appliances
from far, as long as the connection to the internet is accessible. We will be providing a small
scale project in order to show how it is work in a real time (working prototype).
Name given for the system is Laboratory Automation System. This system created
because of few observations were made especially during the day at 8.00am lab where the
labs were locked and students and lecturers or tutors have to wait for the security to open it.
Instead of coming over to open the lab, we create this system which can be controlled by the
one in charged in the control room. This is less time consuming rather than coming over to
lab and to open the lab for the students and lecturers.
The group consist of 5 members, named as Muhammad Nazmi bin Mat Asri as the
group leader, Afiq Aiman bin Zamri, Amelia Asyiqin Binti Mohamad, Khalida Adeeba binti
Mohd Zailan and Wan Nor Suhaili binti Wan Zahari. Tasks were given accordingly to each
members in order to complete this project and documentations.
Page 1

CONTENT
I OVERVIEW
II SOFTWARE PROJECT MANAGEMENT PLAN (SPMP)
1.0
INTRODUCTION
1.1
Project Overview
1.2
Project Deliverables
2.0
3.0
PROJECT ORGANISATION
2.1
Software Process Model
2.2
Roles and responsibilities
2.3
Tools and Techniques
10
PROJECT MANAGEMENT PLAN
11
3.1 Tasks
3.1.1 Task
11
3.1.1.1 Description
11
3.1.1.2 Deliverables and Milestones
11
3.1.1.3 Resources Needed
12
3.1.1.4 Dependencies and Constraints
12
3.1.1.5 Risks and Contingencies
13
Page 2

III SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
1.0
2.0
INDTRODUCTION
19
1.1.
Product overview
19
1.2
Scope
19
SPECIFIC REQUIREMENT
20
2.1.
External Interface Requirement
20
2.2.
Software System Attributes
21
ADDITIONAL MATERIAL
24
IV SOFTWARE DESIGN DESCRIPTION (SDD)
30
1.0
INTRODUCTION
32
2.0
SYSTEM ARCHITECTURAL DESIGN
33
2.1 Chosen System Architecture
33
DETAILED DESCIPTION OF COMPONENTS
43
3.0
3.1
Physical arrangement of devices and Communication and installed software

components on devices
37
USER INTERFACE DESIGN
44
4.1. Screen Images
45
4.2 Objects and Action
47
Page 3
4.0

V SOFTWARE TESTING DOCUMENTATION (STD)
1.0
2.0
INTRODUCTION
50
1.1.
System Overview
50
1.2.
Testing Approach
51
TEST PLAN
2.1
Features to be tested
52
2.2
Features not to be tested
52
2.3
Testing Tools and Environment
53
3.0
TEST CASES
65
4.0
ADDITIONAL MATERIAL (TEST LOGS)
67
VI REFERENCES
69
Page 4
Software Project Management Plan

Final version
13th August 2015
Universiti Teknologi PETRONAS
Page 5

Software Project Management Plan (SPMP)
Table of Contents
1 INTRODUCTION
1.1 Project Overview
1.2 Project Deliverables
2 PROJECT ORGANISATIONS
2.1 Software Process Model
2.2 Roles and Responsibilities
2.3 Tools and Techniques
10
3 PROJECT MANAGEMENT PLAN

3.1 Tasks
3.1.1 Task
3.1.1.1 Description
11
3.1.1.2 Deliverables and Milestones
11
3.1.1.3 Resources Needed
12
3.1.1.4 Dependencies and Constraints
12
3.1.1.5 Risks and Contingencies
13
3.2 Assignments
14
3.3 Timetable
15
Page 6

1 INTRODUCTION
1.1 Project Overview
This idea came up when we notice that there are quite some time it happened that the
laboratory door is not open and the students have to wait until the lecturer came because only
the lecturer or security department (control room) have the access to the door. This project is
to create a system for laboratory door as well light which can control the behavior of those
particular appliances. The system can be controlled from a distance and the controller will be
included in the system as well. The controller is a web that will be associated with the
system and use Wi-Fi as connection medium. The concept that we are going to implement is
Internet of Things (IOT), which allow the specific user to have control over the appliances
from far, as long as the connection to the internet is accessible. When you access the
webserver from your browser of choice, you will have a big button that triggers the
laboratory door via a relay. We will wire a very basic circuit to the Pi's GPIO pins and upload
a website that triggers the circuit. When the relay is triggered, it closes the circuit hooked up
to the laboratory door motor and opens the door.
1.2 Project Deliverables
This project will be used for our targeted group that is our security department, for them to
easily open the door and lighting from far. We must buy the breadboard, relay, raspberry pi,
wire and laboratory motor. Then, we will combine the apparatus and we will use HTML, CSS
and JavaScript for the. While for the raspberry pi will use Webiopi application in the
Raspberry pi to control the GPIO pin inside the pi. Lastly, to connect the pi and the web using
HTML and REST API. The cost for this project is less than RM 50.00 for small scale project.
This project will be tested using prototype. The due for this project is the end of this August
Page 7

2015, thats mean our timeline for our projects is about 3 months that starting from June 2015
until August 2015.
2 PROJECT ORGANISATIONS
2.1 Software process model
Our project will follow an incremental and an iterative development model for its
deliverables. The development will be done in several phases and each phase will represent a
complete development cycle, with certain functionality of the system delivered at the end of
each phase. Additionally, the project phases with start, finish dated and goals for each phase
are outlined in table below.
Phase
Start and finish date
Project startup
26 / 05/ 2015 30 / 05/ 2015
Phase goals
-
Strategy planning
Learning about the existing

technologies
regarding
automation system
Requirement
01/ 06/ 2015 15/ 06/ 2015
Become familiar with the

requirement
Design the prototype
Start searching tools for the

prototype
Phase 1
16/ 06/ 2015 17/ 07/ 2015
Start doing the prototype
Component characterization
format
Phase 2
18/ 07/ 2015 31/ 07/ 2015
Constraint checker
Page 8

Phase 3
01/ 08/ 2015 10/ 08/ 2015
Final touch up
Each of the team members will create a list of tasks to be completed for the upcoming phase
of the project. Then the time for each task will be allocated, followed by the workload
balancing of the tasks. At the completion of each phase a postmortem analysis will be done to
analyze the previous phase. All tasks that we not completed during a phase will be recorded
and scheduled for completion in the upcoming phase.
2.2 Roles and responsibilities

The team structure is hierarchical. There is a team leader, and the rest of the roles are
assigned to the other tasks. All team members have their own area of responsibility and
everyone is expected to contribute equally to the project. The team will engage in regular
monthly meetings. Additionally team members will communicate by Facebook for the
compilation of documents and WhatsApp as our main communication medium. Personal
communication between team members is strongly encouraged.
Roles
Team leader
List of responsibilities
-
Motivate the team members to perform their task
Help the team in allocating the tasks and resolving

issues
Development manager
Planning manager
Producing the development strategy
Producing the design specification
Implement the product
Developing the build, integration and system test plan
Developing the test materials and running the tests
Lead in producing the task plan for next phase
Page 9
Process manager
Lead in producing the schedule for the next phase
Track the team progress against the plan
Lead in producing and tracking the quality plan
-alerts the team to quality problem
Lead in defining and documenting its processes and in

maintaining the process improvement process
Establish and maintain the teams development

standards
Support manager
Lead in determining its support needs and in obtaining

the needed tools and facilities
Maintain the teams issue and risk tracking system
Manage the configuration management system
2.3 tools and technique
Additional tools that will be used are: breadboard, relay, raspberry pi , wire and laboratory
motor. Then, we will combine the apparatus and we will used HTML , CSS and JavaScript
for the. While for the raspberry pi will use Webiopi application in the Raspberry pi to control
the GPIO pin inside the pi. Lastly, to connect the pi and the web using HTML and REST
API.
Page 10

3 PROJECT MANAGEMENT PLAN
3.1 Task
3.1.1 Task -1
3.1.1.1 Description
The aim of this project is to help the Security department to create a system for
laboratory which can control the behavior of those particular appliances. The system can be
controlled from a distance and the controller will be included in the system as well. There are
a lot of risks and constraints that need to overview about the production so that it is inclined
with what we want to achieve.
3.1.1.2 Deliverables milestones
Milestone
Complete
Date
gathering 15/ 06/ 2015
Description
All requirement for the security to
requirements
detect which want to be opened
Complete design the 17/ 07/ 2015
Design the system prototype and
prototype
its functionality
Complete coding the 31/ 07/ 2015
All coding completed resulting in
prototype
software prototype
Complete testing and 10/ 08/ 2015
All functionality had been tested
debugging
and identified errors corrected
the
prototype
Complete production
Complete
the
prototype
and
Page 11

of the prototype
documentation
operations
transitioned
group
to
to
begin
production
3.1.1.3 Resources needed
Hardware: breadboard, relay, raspberry pi ,wire and laboratory motor
Software: HTML, CSS, JavaScript, Webiopi and REST API
3.1.1.4 Dependencies and constraints
There are constraints that may arise along the way of our project because of resources needed
for the project that cannot be obtained and maintained.
Firstly, time constraints. The time given from end of May until early August 2015.
Actually we only given 2 months to complete this project with our 18 credit hour this sem.
We also rarely manage to meet the client because of time constraints and unavailability of
both parties. So this will make there possibilities for us to not meet clients requirement or
misunderstanding from the clients requirement.
Next, the limitation of UI or design on the web itself. It is because the CSS code
hardly or cannot overwrite and need to built it in CSS application of Webiopi that was the
software for the pi. Webiopi is a component that will interact the pi with the HTML code
from the web. So we need to have Webiopi application.
Page 12

3.1.1.5 Risk and contingencies
There are a lot of risks need to be taken note when seeing the clients or any stakeholder.
Firstly, when we use an electrical apparatus, we have to take note the voltage used. If
the voltage used or output voltage is higher from input voltage, the raspberry pi will crash or
broken and not working. So to prevent our hardware easily crash, we must take care all about
that. This also one way how we want to make our project more productive and prevent for
wastage in term of buying extra things because of the experiment was not going well.
Then, project management process. We have to well plan our project so that
everything within the time frame given and will not delay. This is the important of team
leader to make sure everything is in the right places to prevent from delay of the project. We
also can make a Gantt chart to make our schedule more visible and revisable for everyone.
We also must make a correct budget and allocate correctly within our budget as a student.
Page 13

3.2 Assignments
Nazmi Asri is assigned as the Project Manager who will do the technical part of
preparing materials for the prototype. The rest of the team acts as System Analysts, as
required at the current level of development of the system. Under Nazmis
supervision, Khalida Adeeba leads the estimation of project size, effort and schedule
in the project management area. Amelia designed the work plan and developed the
Gantt chart which is approved by the project manager and the team members. Afiq
gathers the requirements mostly via the observations of the current system. From the
substances gathered, Suhaili leads the process of preparing the requirement definition
document. The review of the system is finally prepared by Afiq based on the
planning, analysis and design of the system that has been made and approved by
Nazmi Asri.
Page 14

3.3 Project Timetable
In order to finish this project on time, we had prepared a timetable allocating each member
with their particular job. Allocation of jobs is important as we know what to do first before
one another. This help to ease the flow of our project. We managed to clear out our project in
time of 2 Months and 18 days.
Name
Job scopes
Time
Nazmi
Gather material for prototype
1 Week
Afiq
Gather requirements for the project
4 Days
Adeeba
System Project Management Plan
1 Week
Suhaili
System Requirement Specification
1 Week
Amelia
System Design Description
1 Week
Nazmi
System Testing Development
2 Weeks
Nazmi
Monitor the workflow
All the time
ALL
Implementing the system and Working Prototype
1 Month
Afiq
Page 15
Software Requirements Specification

Final version
13th August 2015
Table of Contents
Page 16

1.
2.
3.
INTRODUCTION
19
1.1
Overview
19
1.2
Scope
19
SPECIFIC REQUIREMENTS
20
2.1
External Interface Requirements
20
2.1.1
User Interfaces
20
2.1.2
Hardware Interfaces
20
2.1.3
Software Interfaces
21
2.1.4
Communications Protocols
21
2.2
Software Product Features
21
2.3
21
2.3.1
Reliability
22
2.3.2
Availability
22
2.3.3
Security
22
2.3.4
Maintainability
22
2.3.5
Portability
23
2.3.6
Performance
23
ADDITIONAL MATERIAL
24
Page 17

Appendix A: Use Case
24
Appendix B: Sequence Diagram
25
Page 18

1.
INTRODUCTION
1.1
Purpose
The purpose of this SRS is to provide details about the workings of the Laboratory
Automation System. The details are to be sufficient enough that the system (including the
components) to be built. It is intended to be readable by the developer team involved. This
document provides the description of the system, laying out the functional and non-functional
requirements and use cases that describe the interactions the users will have with the
software.
1.2
Scope
The product to be produced is a Laboratory Automation System. This system will basically
allow the behavior of particular appliances to be controlled from a distance. Basic properties
and features will be described, which include the concept, medium of connection and
controller as well as the components, the actions it is suggested to, and shall perform. The
system is aimed to help security department to easily control the particular appliances
behavior and reduce time consumption in order to move from one to another laboratory in
comparison to a conventional manual door.
Page 19

2. SPECIFIC REQUIREMENTS
2.1
External Interface Requirements
This section shall describe the interface requirement for the laboratory automation
system. They specify the way the user shall interact with the system as well as define
the necessary hardware interfaces and communication interfaces required by the
software to support the main function.
2.1.1
User Interfaces
The user interface shall follow basic Window style and functionality
conventions. The interface has two buttons on the screen with necessary
description to be provided on how to use the system. User need to login using
the given username and password before making any command. One button
will represent light and another one for door. The color of the button means;
green for on and red for off. Each click of the button will trigger the behavior
of the appliances thus perform the desired action. For example, when the user
click on the button light (in color of red), the button will trigger the light in the
laboratory room to be turned on. Thus the color of the button will change to
green, means the light is on.
2.1.2
Hardware Interfaces
The system will be using a controller which can control the appliances from a
distance. This controller will be connected through Wi-Fi connection and
perform action received by webserver using basic networking protocols.
Page 20
2.1.3
Software Interfaces
The system is using the concept of Internet of Thing (IoT) which control the
behavior of things using the medium of Internet connection. The webserver
shall be able to be accessed from any type of operating system as long as there
is web browser. The web should be able to be accessed from anywhere and
anytime. The webserver can be open using mobile android or web.
2.1.4
Communications Protocols
The button feature in the webserver shall perform it function based on the
desired outcome. The green button shall only be able to be activated when the
door is locked and vice versa. The security system must be ensured by
providing the security department with a proper login username and password
to prohibit ant unauthorized access.
2.2
Software Product Features
The main features of the system will be:
Button for light and door
Different button color code control
Contact detail
Description on usage
Page 21
2.3
Wi-Fi connector and receiver
Login access for authentication
Lock or unlock door
Turn on or off light

2.3.1
Reliability
The system is expected to be reliable to use over time and not sensitive that
prone to cause failure. 2.3.2
Availability
The system can be accessed anytime depending on the availability of

Wi-Fi connection
2.3.3
Security
Only authorized people especially from security department can access
the webserver and gain the login information
Fail authentication login more than 3 times should be blocked and alert
notification will be sent to main control room
2.3.4
Maintainability
The system uses a single page webpage which is not complex and
eases the maintenance.
Page 22

2.3.5
Portability
The webpage can be opened in any operating system available along as
there is web browser.
2.3.6
Both web and mobile android can be used as a platform
Performance
The system should respond to action made by user with no delay more
than 20 seconds
Page 23

3.
ADDITIONAL MATERIAL
Appendix A: Use Case Diagram
Page 24

Appendix B: Sequence Diagram
Page 25
Page 26
Page 27
Page 28
Page 29
SOFTWARE DESIGN DESCRIPTION

Final Version
13th August 2015
Page 30

Table of Content
1.
2.
3.
INTRODUCTION
32
1.1
32
Design Overview
SYSTEM ARCHITECTURAL DESIGN
33
2.1
33
Chosen System Architecture
DETAILED DESCRIPTION OF COMPONENTS
43
3.1 Component
43
4.
USER INTERFACE DESIGN
44
4.1
Description of the User Interface
44
4.1.1 Screen Images
45
4.1.2 Objects and Action
47
Page 31

INTRODUCTION
1.1 Design Overview
The software system being produced called Laboratory Automation System. It is
being produced to ease the student to get access to any laboratory door via the Internet. They
do not have to wait for the lecturer or security to come and open the door using their card.
This system is designed to provide automation support for the process of operating the door
and light in the particular laboratory. This system is largely cross-platform and is available to
any student who has a stable Internet connection. The system will be run on a central server
with each user will instruct them by a click on a particular instruction interface through a web
browser. The Laboratory Automation System will allow every verified student to have access
with web server. This project mainly focus on the problem faced by most of the student by
initiating the automating and standardizing automation system, providing the most effective
way to overcome the problem. Our project is design to ease everyone that may want to use
the room. This project will enable user to have control at any time as long as they are verified
use to use our website. Our project enable people to log in and choose which ever option
either door or light that they want to turn it on or off.
Page 32

2. SYSTEM ARCHITECTURAL DESIGN
2.1 Chosen System Architecture
This system works anywhere as long as there is internet access, it is a web based so it
is applicable for mobile phones as well as personal computer. This idea came up when we
notice that there are quite some time it happened that the laboratory door is not open and the
students have to wait until the lecturer came because only the lecturer have the access to the
door. This project is to create a system for laboratory door which can control the behaviour
of those particular appliances. The system can be controlled from a distance and the
controller will be included in the system as well. The controller is a web or a mobile
application that will be associated with the system and use Wi-Fi as connection medium. The
concept that we are going to implement is Internet of Things (IOT), which allow the specific
user to have control over the appliances from far, as long as the connection to the internet is
accessible. The platform that we are using is web, the code is written in html and JavaScript
and using mobile using Android for the security easily access everywhere and anytime. We
also used Raspberry Pi as the controller which is easy for us access that is connect through
Wi-Fi. When you access the webserver from your browser of choice, you will have a big
button that triggers the laboratory door via a relay. We will wire a very basic circuit to the
Pi's GPIO pins and upload a website that triggers the circuit. When the relay is triggered, it
closes the circuit hooked up to the laboratory door motor and opens the door.
Page 33
Use Case Diagram
Page 34
Activity Diagram
Figure 2.1.2: Login
Page 35
Figure 2.1.3: Verify user
Page 36
Figure 2.1.4: Browse page
Page 37
Figure 2.1.5: logout
Page 38

Sequence Diagram
Page 39
Page 40
Page 41
Page 42

3. DETAILED DESCRIPTIONS OF COMPONENTS
3.1 Component
Raspberry Pi
-
The Raspberry Pi is a low cost, credit-card sized computer that plugs into a
computer monitor or TV, and uses a standard keyboard and mouse. It is a capable
little device that enables people of all ages to explore computing, and to learn how
to program in languages like Scratch and Python.
We use application webiopi in raspberry pi to control GPIO pin in raspberry pi for

general purpose input and output.
We also use HTML, CSS, and JavaScript for the website.

To connect website and raspberry pi we did apply HTML and REST API.
Page 43

4 USER INTERFACE DESIGN
4.1 Description of the User Interface
The user interface shall follow basic Window style and functionality
conventions. The interface has two buttons on the screen with necessary
description to be provided on how to use the system. User need to login using
the given username and password before making any command. One button
will represent light and another one for door. The colour of the button means;
green for on and red for off. Each click of the button will trigger the behaviour
of the appliances thus perform the desired action. For example, when the user
click on the button light (in color of red), the button will trigger the light in the
laboratory room to be turned on. Thus the color of the button will change to
green, means the light is on. The button feature in the webserver shall perform
it function based on the desired outcome. The green button shall only be able
to be activated when the door is locked and vice versa. The security system
must be ensured by providing the security department with a proper login
username and password to prohibit ant unauthorized access.
Page 44

4.1.1 Screen Images
Page 45
Figure 3: Main Page interface
Page 46

4.1.2 Object and Action
There are some object on screen which are :
* Button for light and door
* Different button color code control
* Contact detail
* Description on usage
* Wi-Fi connector and receiver
* Login access for authentication
* Lock or unlock door
* Turn on or off light

The action needed to access this server is that login and then choose option either
door or light and then set it to or off.
Page 47
Software Test Documentation

Final version
13th August 2015
Page 48

1 INTRODUCTION
1.1 System Overview
50
1.2 Test Approach
51
2 TEST PLAN
2.1 Features to be Tested
52
2.2 Features not to be Tested
52
2.3 Testing Tools and Environment
53
2.3.1
Testing tools (Development Testing)
54
2.3.2
Testing Tools (Interface Testing)
54
2.3.3
Testing Tools (Functionality Testing)
55
2.3.4
Testing Tools (HTML and CSS)
56
2.3.5
Testing Tools (Compatibility Testing)
57
2.3.6
Testing Tools (Performance Testing )
58
2.3.7
Testing Tools (Usability Testing)
59
2.3.8
Testing Tools (Security Testing)
60
2.3.9 Testing Tools (White Box Testing)
62
3 TEST CASES
3.1 Case 1
65
3.1.1 Purpose
3.1.2 Inputs
3.1.3 Expected Outputs & Pass/Fail criteria
3.1.4 Test Procedure
Page 49

3.2 Case 2
66
3.2.1 Purpose
3.2.2 Inputs
3.2.3 Expected Outputs & Pass/Fail Criteria
3.2.4 Test Procedue
4 ADDITIONAL MATERIAL (including appendix A)
APPENDIX A. TEST LOGS
4.1 Log for test case 1
67
4.2 Log for test case 2
68
Page 50

1. INTRODUCTION
1.1 SYSTEM OVERVIEW
This project is to create a system for laboratory door as well light which can control
the behaviour of those particular appliances. The system can be controlled from a distance
and the controller will be included in the system as well. The controller is a web that will
be associated with the system and use Wi-Fi as connection medium. The concept that we
are going to implement is Internet of Things (IOT), which allow the specific user to have
control over the appliances from far, as long as the connection to the internet is
accessible. When you access the webserver from your browser of choice, you will have a
big button that triggers the laboratory door via a relay. We will wire a very basic circuit to
the Pi's GPIO pins and upload a website that triggers the circuit. When the relay is
triggered, it closes the circuit hooked up to the laboratory door motor and opens the door.
Testing the Lab Auto System is intended to show that this system is working and
functioning well. We are referring the Authorities here is Security Department members
who are working in the Control Room to monitor the campus including controlling the
doors and lights. Furthermore, testing will enable us to detect the errors from the system.
When we test the software, we execute a program using artificial data. We check the
results of the test run for errors, anomalies or information about the systems nonfunctional attributes. The goal of this testing stage is;
To demonstrate on how to use the system to the authorities like in this case is the
security department.
To discover situations in which the behaviour of the software is incorrect, undesirable
or does not conform to its specification.
Page 51

1.2 TEST APPROACH
We are calling all the guards for demonstrating the usage of the Lab Auto System.
After being explained the steps, we took their photographs as we are using face
recognition for them to unlock the door and lights for labs. A few references have been
listed below for testing purposes:
#
Document Identifier
Document Title
[Ref1] ID
Authorities ID
[Ref2] Password
Authorities Password
[Ref3] Light
Button to switch on the Lights
[Ref4] Door
Button to open the door
Standard and Regulatory Reference
Document Identifier
[STD1] Password
Document Title
This password for guards are important for them to unlock
the door and switch on the lights
Page 52

2
TEST PLAN
2.1 Features to be tested
For Lab Auto System, the guards will need their ID number and password in
order for them to have the accessibility to the system. Only one computer can operates
the system at one time. This is to avoid from misuse from any party that trying to play
around with the system and to maintain the level of security at the lab. Whenever the
guards are login, they will proceed to a webpage that consist a simple buttons of lights
and doors. That buttons have 2 different colors; red and green. Red color indicates the
switch is OFF while green in color indicate the switch is ON.
2.2 Features not to be tested
As our concern, due to time constraint and limited funding, the face
recognition is unable to be tested as we cant get the right time to meet the guards for
a proper photograph session as it will be used for the face recognizing. Moreover, due
to limited time we also unable to find a cheap IP camera and suitable for our project.
Page 53

2.3.1
Testing tools (Development Testing)

2.3.1.1 Hardware preparation
2.3.1.1 This system can run in some devices only such desktop and
laptop. We cannot use the system in mobile phone or smartphone since
it is not a mobile friendly system.
2.3.1.2 Software preparation
2.3.2.1 The system is compatible with any kind of browser for desktop
such as Internet Explorer, Google Chrome, Mozilla Firefox,
Safari and Opera
2.3.1.3 Safety, security and privacy precautions
2.3.3.1 For safety, security and privacy precautions, we use login
system before anyone can use the system.
2.3.2
Testing Tools (Interface Testing)

2.3.2.1 Objectives are to detect faults due to interface errors or invalid
assumptions about interfaces. This testing is applicable during the
login. The interfaces of the system are same before the login but
different because it will show another screen that display the buttons of
Door and Light.
Page 54

2.3.3
Testing Tools (Functionality Testing)

2.3.3.1 The objective of this test is to check if the system is as per the
specifications the customer intended for it as well as the functional
requirements
that
have
been
showed
in
the
development
documentation.
2.3.3.3.1
Testing activities are included:
2.3.3.3.1.1
Outgoing links
2.3.3.3.1.2
Internal links
2.3.3.3.1.3
Anchor links
2.3.3.3.2
Test cookies are working as expected.
2.3.3.3.2.1
Cookies are used by websites to remember

active user sessions so the user does not need to
re-login every time the user use the website
2.3.3.3.2.2
Testing cookies are deleted when expired
2.3.3.3.2.3
Testing cookies received when user login
2.3.3.3.2.4
Tools that can be used: IBM Rational, Selenium
Page 55

2.3.4
Testing Tools (HTML and CSS)

2.3.4.1 To ensure that search engines can crawl your site easily. This will
include
2.3.4.1.1
Checking for syntax errors
2.3.4.1.2
Readable colour schemas
2.3.4.1.3
Standard compliance. Ensure standards such W3C,

OASIS, IETF, ISO, ECMA, or WS-I are followed.
2.3.4.2 Functional Test Scenarios:

2.3.4.2.1
Test the system should not display the error message for
optional fields.
2.3.4.2.2
Test the functionality of the buttons available
2.3.4.2.3
Test the java script is properly working in different

browsers (IE, Firefox, Chrome, safari and Opera).
2.3.4.2.4
Test to see what happens if a user deletes cookies while

in the site.
2.3.4.2.5
Test to see what happens if a user deletes cookies after

visiting a site.
Page 56

2.3.5
Testing Tools (Compatibility Testing)

2.3.5.1 Ensures that your web application displays correctly across different
devices.
2.3.5.1.1
Browser Compatibility Test: Same website in different

browsers will display differently. You need to test if
your web application is being displayed correctly across
browsers, JavaScript, AJAX and authentication is
working fine.
2.3.5.1.2
To determine if the software is compatible with other

elements of a system with which it should operate, e.g.
Browsers, Operating Systems, or hardware.
2.3.5.1.3Compatibility Test Scenarios:

2.3.5.1.1
Test the website in different browsers (IE,

Firefox, and Chrome) and ensure the website is
displaying properly.
2.3.5.1.3.2
Test
the
HTML
version
being
used
is
compatible with appropriate browser versions.

2.3.5.1.3
Test the images display correctly in different

browsers.
2.3.5.1.4
Test the fonts are usable in different browsers.

Test the java script code is usable in different
browsers.
Page 57

2.3.6 Testing Tools (Performance Testing)
2.3.6.1 Ensure site works under all loads. Testing activities will include
but not limited to;
2.3.6.1.1
Website application response times at different

connection speeds
2.3.6.1.2
Load test your web application to determine its

behavior under normal and peak loads
2.3.6.1.3
Stress tests your web site to determine its break

point when pushed to beyond normal loads at
peak time.
2.3.6.1.4
Test if a crash occurs due to peak load, how

does the site recover from such an event
2.3.6.2 Performance testing is conducted to evaluate the compliance of

a
system
or
component
with
specified
performance
requirements.
2.3.6.2.1
To determine the performance, stability and

scalability of an application under different load
conditions.
2.3.6.2.2
To
evaluate
product
and/or
hardware
to
determine if it can handle projected load

volumes.
Page 58

2.3.6.2.3
To determine if the current architecture can

support the application at peak user levels.
2.3.7 Testing Tools (Usability Testing)

2.3.7.1
Usability testing has now become a vital part of any web based
project. It can be carried out by testers by our team or a small
focus group of authorities of the web application.
2.3.7.1.1
Test the site Navigation:
2.3.7.1.1.1
Buttons or Links to different pages on your site

should be easily visible and consistent on all
webpages
2.3.7.1.2
Test the Content:
2.3.7.1.2.1
Content should be legible with no spelling or

grammatical errors.
2.3.7.1.2.2
Images if present should contain an "alt" text
2.3.7.2 Usability Test Scenarios:

2.3.7.2.1
Web page content should be correct without any

spelling or grammatical errors
2.3.7.2.2
All the text should be properly aligned.
2.3.7.2.3
All the buttons should be in a standard format and size.
2.3.7.2.4
Check the end user can run the system without

frustration.
Page 59

2.3.7.2.5
Check the site on different resolutions (640 x 480,

600x800)
2.3.7.2.6
2.3.8
Check for broken links and images.
Testing Tools (Security Testing)

2.3.8.1 Security testing is vital for control room usage website that controls the
safety of the labs (doors and lights).
2.3.8.2 Test unauthorized access to secure pages should not be permitted
Figure 1: Username and password are needed to login into the page
Page 60
Figure 2: The user will enter the username and password
Page 61

2.3.9
Testing Tools (White Box Testing)

2.3.9.1 Codes for functioning buttons (door & light)
2.3.9.2 White box testing are involves the testing of the software/system code
for the following:
2.3.9.2.1
Internal security holes
2.3.9.2.2
Broken or poorly structured paths in the coding process
2.3.9.2.3
The flow of specific inputs through the code
2.3.9.2.4
Expected output
2.3.9.2.5The functionality of conditional loops
Page 62
2.3.9.2.6
Testing of each statement, object and function on an individual

basis
2.3.9.3
The way that we do the white box testing are:

2.3.9.3.1
Understand the source code
2.3.9.3.1.1
The first thing a tester will often do is learn and

understand the source code of the application
2.8.3.1.1.2
Since the white box testing involves the testing of the

inner workings of an application, the tester must be very
knowledgeable in the programming languages used in
the applications they are testing, in our case is HTML,
CSS, Javascript, JQuery, AJAX and WebioPi coding.
2.3.9.3.2
Create test cases and execute
2.3.9.3.2.1
The second basis step to white box testing involves

testing the applications source code for the proper flow
and structure.
2.3.9.3.2.2
One way is writing more code to test the applications

source code.
2.3.9.3.2.3
The tester will develop little tests for each process or

series of processes in the application.
Page 63

2.3.9.3.4
This requires that the tester must have intimate

knowledge of the code and is often done by the
developer.
2.3.9.3.5
Other methods of testing are manual testing, try and

error listing.
Page 64

3.0 TEST CASES
3.1 Test Case 1 Login Page (user=Security)
3.1.1 Purpose
To test the login page usability
3.1.2 Inputs
Securitys username
Securitys password.
3.1.3 Expected Outputs and Pass/Fail Criteria
Security should be able to login successfully and the system will display the
home screen back.
The process failed if the security are not able login (not because of wrong
username or password)
Navigate to the login page
Provide valid username and password
Press enter
Page 65

3.2 Test Case 2 Login Page (user=Security Venue: Office (Outside the control room))
3.2.1 Purpose
To test the login page usability
3.2.2 Inputs
Securitys Username
Securitys password.
3.2.3 Expected Outputs and Pass/Fail Criteria
Security should be able to login successfully and the system will display the
home page back.
The process failed if the Security are not able to login (not because of wrong
username or password)
Navigate to the login page
Provide valid username and password
Press enter
Page 66

4.0 ADDITIONAL MATERIAL (TEST LOGS)
4.1 Logs for Test Case 1 Login Page
4.1.1 Test Results
The purpose is to test the login page usability by having security as the user. Several
Security members sample input data was inserted. Below are the test results:
Input Data
Expected Result
Actual
Comment
Result
Username= webiopi
Successfully
Password=rahimi432
logged in into the
Passed
system
Username= webiopi
Unsuccessfully
FAILED Only one user can
Password=tingtang143
logged in into the
have the access at a
system
time to prevent the

misuse of the buttons
and ruin the system.
Page 67

4.0 ADDITIONAL MATERIAL (TEST LOGS)
4.2 Logs for Test Case 2 Login Page (different place)
4.2.1 Test Results
The purpose is to test the login page usability by having Security as the user. Securitys
sample input data was used. Below are the test results:
Input Data
Expected Result
Actual
Comment
Result
FAILED Couldnt
log
in
Username=webiopi
Unsuccessfully
Password=rahimi432
logged in into the
because
system
functions at control
it
only
room. One of the ways

to prevent misuse of
the system.
Page 68

VI REFERENCES
1) http://www.guru99.com/web-application-testing.html
2) http://www.guru99.com/white-box-testing.html
3) http://www.guru99.com/complete-web-application-testing-chec
4) http://www.softwaretestinghelp.com/web-application-testing/
5) http://www.tutorialspoint.com/s/web_application_testing.htm
6) https://code.google.com/p/webiopi/wiki/INSTALL?tm=6
7) https://code.google.com/p/webiopi/wiki/CONFIGURATION
Page 69

Example Software Engineering Paperwork

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Example Software Engineering Paperwork

Caricato da

Copyright:

Formati disponibili

Software Engineering : TDB 2163 2015

TDB 2163 SOFTWARE ENGINEERING

LABORATORY AUTOMATION SYSTEM

Date: 14th August 2015

2. MUHAMMAD NAZMI BIN MAT ASRI

3. AMELIA ASYIQIN BINTI MOHAMAD

4. KHALIDA ADEEBA BINTI MOHD ZAILAN 19271

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

II SOFTWARE PROJECT MANAGEMENT PLAN (SPMP)

Software Process Model

Roles and responsibilities

Tools and Techniques

PROJECT MANAGEMENT PLAN

3.1.1.2 Deliverables and Milestones

3.1.1.3 Resources Needed

3.1.1.4 Dependencies and Constraints

3.1.1.5 Risks and Contingencies

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

External Interface Requirement

Software System Attributes

IV SOFTWARE DESIGN DESCRIPTION (SDD)

SYSTEM ARCHITECTURAL DESIGN

2.1 Chosen System Architecture

DETAILED DESCIPTION OF COMPONENTS

Physical arrangement of devices and Communication and installed software

USER INTERFACE DESIGN

4.1. Screen Images

4.2 Objects and Action

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

Features not to be tested

Testing Tools and Environment

ADDITIONAL MATERIAL (TEST LOGS)

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

Software Project Management Plan

LABORATORY AUTOMATION SYSTEM

Universiti Teknologi PETRONAS

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

1.2 Project Deliverables

2.2 Roles and Responsibilities

2.3 Tools and Techniques

3 PROJECT MANAGEMENT PLAN

3.1.1.2 Deliverables and Milestones

3.1.1.3 Resources Needed

3.1.1.4 Dependencies and Constraints

3.1.1.5 Risks and Contingencies

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

1.1 Project Overview

1.2 Project Deliverables

LABORATORY AUTOMATION SYSTEM

Software Engineering : TDB 2163 2015

2.1 Software process model

Start and finish date

26 / 05/ 2015 30 / 05/ 2015

Learning about the existing

01/ 06/ 2015 15/ 06/ 2015