SQE

SOFTWARE QUALITY ENGINEERING INDIVIDUAL ASSIGNMENT
Abstract
This document discussed about how to develop a quality and standard Restaurant Directory
and Food Reservation system. The selected methodology for developing the system is
waterfall model which the details of phases will be discuss in the document. Moreover,
quality attributes and types of quality assurance process has been documented in one of the
topic. Time, effort and cost of the project will be estimated and discussed in the document.
Partial of software quality assurance plan (SQAP) also could be find in this document and the
full document will be found in the CD. Last but not least, software metrics for the selected
attribute will be the last main topic that will be discuss in this document.
PHAN YONG SHIN TP 027858 1

Table of Contents
Abstract......................................................................................................................................1
1.0 Introduction..........................................................................................................................3
1.1 Overview of the system....................................................................................................3
1.2 Purpose and Scope of the system.....................................................................................4
2.0 Methodology........................................................................................................................5
3.0 Quality Assurance Process...................................................................................................8
3.1 Software Quality Attributes..............................................................................................8
3.2 Five Types of Quality Assurance Process..........................................................................10
3.2.1 Configuration Management........................................................................................10
3.2.2 Verification and Validation..........................................................................................11
3.2.3 Types of Testing..........................................................................................................12
3.2.4 Defect Tracking...........................................................................................................19
3.2.5 System Testing............................................................................................................19
4.0 Estimation..........................................................................................................................20
4.1 UFP Calculation Form...................................................................................................20
4.2 RCAF.............................................................................................................................22
4.3 Technical Complexity Factor.........................................................................................23
4.4 Functional Point.............................................................................................................23
4.5 Size of Product...............................................................................................................24
4.6 Effort..............................................................................................................................25
4.7 Schedule.........................................................................................................................25
4.8 Cost................................................................................................................................25
5.0 Software Quality Assurance Plan (SQAP).........................................................................26
5.1 Purpose...........................................................................................................................26
5.2 Scope..............................................................................................................................26
6.0 Software Metrics................................................................................................................27
6.1 Performance...................................................................................................................27
6.2 Maintainability...............................................................................................................28
6.3 Usability.........................................................................................................................29
7.0 Conclusion and Recommendation......................................................................................30
7.1 Recommendation............................................................................................................30
8.0 References..........................................................................................................................31
References................................................................................................................................31

1.0 Introduction
1.1 Overview of the system
Restaurant Directory and Food Reservation system is an android mobile application system
that could let user book table and order food for the specific restaurant. Besides, user will also
get to browse restaurants information. The application will provide an interface for user to
choose restaurant include with the restaurant food menu all around the worlds. After choosing
it, user could make reservation for table and also most importantly could order food. After
made payment, user just has to reach the restaurant at the reserved times and the food will
directly serve to the user after sitting down.
In conclusion, the system will be providing a platform for user to browse restaurants
information, make reservation for selected restaurant and order food online. Users just have
to decide which restaurant to go and what to eat and the system will done all the other jobs
for the user.
Users involve:
-Restaurant Customer
-Restaurant Staff

1.2 Purpose and Scope of the system

The aim of this project is to develop a mobile application system that could provide,
restaurant promotion, recommend hot or cheap restaurant nearby the user location. The
system also aimed to provide food directory of restaurants for user to make choices easily.
The application also provides user friendly interfaces to attract and improve user experience
when using the application. Besides, it also provides the services for user to reserve time and
table for the specific restaurant and most important order food directly from the application
without having walk in the restaurant. Moreover, the system also provides easy payment for
customer to pay online and the receipt will be send to user e-mail address. All of this function
could solve the problem that stated above.
Objective
There are few objectives that need to follow to accomplish those the purpose.
No Objective
1) Survey which restaurant has promotion and most people
preferred
2) Gather all food menu information from restaurants
3) Research about how the interface of apps should look like
4) Meeting with company that provide payment online system
5) Discuss with restaurant how the reservation system should
work
Table 1: Objective Source : Self-make

2.0 Methodology
The methodology that has been chosen for developing the Restaurant Directory and Food
Reservation system is Waterfall Model. Waterfall Model was the first SDLC Model that has
been used widely in developing software (Tutorialspoint, 2013). It has six phases which is
Requirement Gathering and analysis, System Design, Implementation, Integration and
Testing, Deployment of system and Maintenance. Each of the phase will only be started when
the previous phase has completed. Besides, there will be no overlapping in the phases. The
reason of choosing waterfall model is because the model is simple and easy to understand for
the team to implement. Moreover, waterfall model could ensure the requirements will be well
gathered and understood in the first phase of the methodology. The team could design the
system by following the requirements gathered without having to worry changes of the
requirements. The developer team will make sure all the requirement and design has been
well documented before starting implementing the system. After developed the system,
difference types of testing will be used to ensure the system has met all the documented
requirements and works without error before launching to the market. Team will be receiving
feedback from public after launched the system to android play store. New version of the
system will be available to the market after fixed error or problem of the system.
Figure 1: Waterfall Model phases source: (TutorialsPoint, 2013)

Requirement Analysis
This phase is the phase that analyze and list the requirement for the system. Brain storming,
questionnaire and interview will be used to analyze and gather the requirements or
deliverables of the Restaurant Directory and food reservation application. Besides,
questionnaire and interview will be conducted to gather more requirements. Questionnaire
will be distributing to public to gather user requirements. Interview will be conducted with
professional software engineering that has experience on developing android application to
gather professional suggestion. The requirements or deliverables of the system will be
documented.
System Design
Design phase will involve describing and designing how the data of the system relate and
work to each other. Unified Model Language (UML) will be apply to this phases to specify,
visualize and document the system architecture of this system. The UML diagram that will be
used is Use Case Diagram, Class Diagram, Activity Diagram and Sequence Diagram. The
reason of choosing UML is because the system is developed using Java and is in Object-
Oriented. Thus, class diagram is necessary to visualize how the class interact with each other
based on the requirement gathered. Besides, UML is in graphical form and it is easier to
understand by developer.
Implementation
This is the phase of developing the system based on gathered requirements. Programming and
coding skills will be applying in here to develop the system. The language used to develop
the Restaurant Directory and food reservation application is Java which is also Object-
oriented programming language. After develop a function, unit testing will be conducted to
ensure the system functionalities works fine. Besides, the developed system will also be
verifying with the design and requirements and make changes if there is any function that
does not meet the requirement.
Testing
Testing for the whole system will be conducted in this phase. Bugs and error will be fixed to
ensure there is no problem after release the system to user. The system will keep be tested
until there is no bug and error reported. Unit testing will first be conducted for the testing.

Integration testing will be the next testing after unit testing has finished. After that, user
acceptance testing will be conducted to ensure the system deliverables are accepted by users.
Deployment
This is the phase for the system to release to the market after completed testing phase.
Release plan will be generated in this phase. The process of releasing the application will be
following to the release plan. Restaurant Directory and food reservation application will be
publishing and releasing into android market for user to use in the final stage of release plan.
Maintenance
Maintenance phase involve monitoring the user feedback and provide maintenance to the
system. Bugs fix or requirement update will be applying to the system based on feedback and
bugs report from users to enhance users experience. Update will be release after fixed bugs
or added new function for the system.

3.0 Quality Assurance Process
3.1 Software Quality Attributes

Software quality attributes are the attribute that describe systems intended behaviour within
the system environment (SotfwareArchitecture, 2013). Quality attributes will be provided to
measure the quality of Restaurant Directory and Food Reservation system. There are a lot of
software quality attribute that use to evaluate the quality of the system. Three software quality
attribute will be chosen for the system which is performance, maintainability and usability.
Performance
Performance attribute is an indication of the responsiveness of a system execute any process

or task within a given time (SotfwareArchitecture, 2013). It is important to the system
because a system with low performance will make user frustrated and decrease user
experience. All android phones have limited memory, high usage of memory for an
application will increase the response time of a single task or process. Thus, the system will
be improved by choosing the programming algorithm that could reduce memory consumption
for every tasks and processes. Besides, database server processing will also be increased to
reduce throughput. Developer will be using efficiency query and ensure only data that are
needed will be fetched from the database for the particular process over the network. This
would ensure the system would not load and process unnecessary data and result in
increasing response time and battery consumption of a phone.
Maintainability

Maintainability is the ability of the system to easily make changes and make improvement,
(ADVOSS, 2013). The system will meet this quality attribute to ensure the system could
easily make changes and add new features to meet new business requirement. The system is
developed using java and object oriented programming. Developer will keep the code clean
and documented. Clear and understandable names will be given to all classes, variables and
methods to ensure developer could easily read the programming code when wanted to make
improvement or changes. Documented code will be showing the flow between each classes.
Besides, developer will refactor all the code to an easy understandable way and lesser code
when developer has finished a function. Moreover, the logic code of components will be
design to be cohesive and have low coupling to maximize flexibility to make changes and
replacements.Usability
Usability is an attribute that defines how well the system has met the requirement of users by
being easy to use and providing a good user experience (Andy, 2016). Usability attribute will
be included into the system to assure the system are easy to use and could increase user
experience. To achieve this, the system Graphical User Interface (GUI) will be design as
simple as possible to reduce complexity for user. Each page of the application will be using
the same colour of background and the page title font will be the same. General and
understandable image and word will be used to design a button. For example, a home image
and Home word will be used to design home button so that user could easily understand
that the system will bring user to home page when user has pressed the button. Moreover, too
much of interaction and input flows of a single task or process of the system will be avoided.
For instances, customer basic details will be auto filled in all textboxes and user just has to
choose date, time and number of person from a drop box and press the reserve button to
reserve a restaurant.

3.2 Five Types of Quality Assurance Process

3.2.1 Configuration Management
Configuration management is a set of discipline for evaluate, coordinate and implement
changes that used to construct and maintain a software system (Dobb, 2011). The purpose of
configuration management is to eliminate the confusion and error that will be brought by the
different versions of system. The standard of configuration management will be developed by
the project manager.
Policies and standard for development tools
Policies and standard will be documented for configuration management. The first policy is
use the same version of tools for development of the system. Windows 10 will be the
operating system for every developer machine. Android studio will be the IDE that used to
code the system and SQLite will be the database to store all the data for the system. If there is
a new update version for development tools and it is necessary to be updated, developer team
has to make sure all the developer machine has successfully updated to the new version
before start making changes to the system. Besides, the system that has been released to
public will be named as baseline.
Version Control
When a lot of changes has been made for the system in the future, the new version of the
system will be named version 1, version 2 and more. If the system only has a minor update,
the new version will be named version 1.1 or version 2.1 and more. The table below show the
summarized information that will be use by developer to easy keep track all system version
details. Moreover, the design, developer name, description of new version and source code
also will be documented to keep track the details of the changes. The testing result of the new
version also has to be done and documented. The new version update only will be release to
public after team leader of the project team has reviewed all the document to ensure there will
be no error for the new update.
Version Implemented Revision Approved Approval Description of

Number By Date By Date Change
1.0 Developer Date of the Name of person Date the Description of change
name implemented who approving the version was
version version approved
Table 2:Summary of system version details source: Self-make

3.2.2 Verification and Validation

Verification and validation is the checking processes which verification involves checking
that system conforms to its specification and validation involves checking the final system
whether it meets the expectation of user (Tan, 2013). Static technique checking will be used
for verification and dynamic technique checking will be used for validation. Static technique
involves analysing and checking of system representation and dynamic technique involves
exercising an implementation.
Verification
The system will be verifying by analyst design and reviewing requirement to ensure the
system reflects specific requirement. When the developer finished a function, the function
design and specification will be verifying based on design document and requirement
specification document. For example, the restaurant information page should have four
textboxes for restaurant name, address, contact number and operating hour. Thus, the system
will be checked whether the system provide the above design. Besides, source code
verification will also be done by reviewing the view restaurant information function to check
whether the code will bring out all the data from database and display correctly into four
textboxes.
Validation
Validation will be done when the system has implement finish to ensure the system meets the
expectation of user. The system will be validating by doing user acceptance testing. User
acceptance testing will be explained in the next topic. Testers with no knowledge of
programming will be invited to test the system to validate whether the system has provided
expected result for the tester. For example, tester will choose a restaurant to reserve to
validate whether the outcome of reservation function is compliant with its purpose.

3.2.3 Types of Testing

There are three type of testing which is unit testing, integration testing and user acceptance
testing that will be used to test the system.
Unit Testing
In this testing, all part of testable unit will be taken from the application to test whether it
meet the deliverables (Rouse, [No Date]). Each unit will be tested separately to ensure it do
not have any error. All units will be tested before integrated into a component. For example,
the browse restaurants information functionality will be tested whether the restaurant
information will be display on the screen. The function will be tested by tapping the all
restaurant list button to test whether the correct restaurant information from the database will
be display on the application screen. If there is an error like the restaurant information does
not come out or came out wrong information, the developer has to find the problem and solve
the problem. After solving the problem, the same testing will be tested again to ensure the
problem occurred has been solved. Below is the unit testing form for the proposed system.
TBD in the actual result column stand for To Be determine. If the testing result is as expected,
the TBD in the actual result will be change to As Expected.
Actual
No. Testing Criteria Expected Result
Result
Customer Browse restaurant list
1. Press Cheap restaurant tab System will display Cheap restaurant list TBD
2. Press Restaurant nearby tab System will display restaurant nearby list TBD
3. Press All Restaurant tab System will display all restaurant list TBD
Press all Promotion System will display all restaurant that are
4. TBD
restaurant tab doing promotion
Press a restaurant that has System will pop up a new page
5. been display in the list once displaying specific restaurant TBD
for all four tab information
Customer reserve restaurant
1. Press the reserve button System will pop up reservation page TBD
Enter all required System will validate user entered
2. information and press Next reservation information and only allow TBD
button user to continue if validate successful
Press confirm button in the System will insert a new reservation of
3. TBD
confirm reservation page the customer into database

Food Menu
System will pop up a Food menu page
1. Press food menu button TBD
and display the restaurant food list
System will back to specific restaurant
2. Press back button TBD
page
Feedback
System will pop up feedback page and
1. Press feedback button TBD
display feedback list
Rate for restaurant and press System will pop up message rate
2. TBD
rate button successfully
Enter comment and press System will insert the feedback into
3. TBD
post button database and refresh the feedback list
4. Press back button System will close the feedback page TBD
Customer view reservation
System will print a list of reservation
1. Press My reservation button TBD
that made by the user
System will pop up a new page
Press one of the reservation
2. displaying the selected restaurant TBD
in the list
information
System will pop up a new page showing
3. Press Food Menu button TBD
food menu of the restaurant
Select quantity of food for
System will pop up a new page
4. each of the food listed inside TBD
displaying ordered food information
food menu and press Order
5. Press confirm button System will pop up payment page TBD
System will pop up order complete
Enter all required payment message if user has entered all the
6. TBD
information correct details and an email will be send
to user
Press the back to home
7. System will back to reservation page TBD
button
System will pop up cancel button if the
Swipe one of the reservation reservation has not been cancel and if the
8. TBD
in the list reservation has been cancel, it will pop
up a delete button
The selected reservation will be cancel
9. Press cancel button TBD
and turn to grey colour background
10. Press the delete button The selected reservation will be delete TBD
Search

Enter a name in the search System will print out a list of restaurant
1. TBD
bar that matched the name
2. Press Category tab System will redirect to Category tab TBD
Select a category in the drop Restaurant that fall under the category of
3. TBD
box the drop box will be display
System will pop up specific restaurant
4. Press a restaurant in the list TBD
page
Change Password
Press change password System will display change password
1. TBD
button page
Enter old password and new System will validate the old password
password press change with database and new password with
2. password button confirm password. The system will TBD
update the new password into database if
the it pass the validation
Customer Account
1. Press My account button System will open my account page TBD
Press update account button System will allow user to edit his own
and change the information account and able to update into database
2. TBD
and profile picture, After that
press confirm button
3. Press Log out button System will log out TBD
Staff main menu
1. Select a restaurant ID and TBD
System will display a list of reservation
select a date in Today
of the restaurant on the selected day
Reservation tab
System will display a list of feedback
2. Select Feedback tab TBD
that made by customer
Select a restaurant ID in All System will display all reservation made
3. TBD
Reservation tab by customer
System will display ordered food made
by customer if there is an order.
4. Press one of the reservation TBD
Otherwise it will pop up no order
message
5. Press log out button System will display log out message TBD
box. If press YES, the system will log
out. Otherwise the system will do

nothing and close the message box

Table 3: Unit Testing form Source : Self-make

Integration Testing
Integration testing is a process of which program units are combined together as a group and
tested in multiple ways (Rouse, [No Date]). The purpose of integration testing is to test
whether the components in the Restaurant Directory and food reservation application will
work with each other. For example, integration testing that will be implemented are user
reserve a restaurant and the selected staff home page should display the reservation directly.
When a user reserved a reservation from the back end, the front end view for restaurant staff
will changed and the system should fetch new data from the database. In order to test it, blind
text will be applied in the testing to ensure there is no error in the process. If there is no
update in the staff reservation page after customer reserved, developer has to find the error
and fix it to ensure the component inside the system will works together. Table in the next
page is the table of testing that will be done for the integration testing. TBD stands for To Be
Determine. If the testing result is as expected, the TBD in the actual result will be change to
As Expected.

System Name: Restaurant Directory and food reservation application

Tester Name: Phan Yong Shin (The Developer)
Date: TBD
Time: TBD
Actual
No. Test Element Expected Result
Result
Login with wrong email or System display wrong email
1. TBD
password in Login page. or password message.
Login with valid email and System redirect to customer or
2. TBD
password in Login page. restaurant staff Home page.
System should insert a new
reservation of the customer
3. Reserve a restaurant into database and the TBD
reservation could be found in
My Reservation page
Press Order button without System display no food
4. TBD
ordering a food ordered message
System will insert the order
with the correct information
and will be show in ordered
5. Order some food TBD
food page. Besides, email will
the payment receipt will be
received
The restaurant staff should
6. Write a feedback for a restaurant feedback page should display TBD
the same feedback
Table 4: Integration Testing form source: self-make

User Acceptance Testing
User Acceptance Testing is a testing of software development in which the software is tested
in the real world by the intended audience (Bordo, [No Date]). This testing phase is to test the
satisfaction level of the end-users. In order to test it, a 3 actual end users will be involving in
the testing. Moreover, the system will be evaluating based on few aspects such as graphical
user interface (GUI), feedback message and response time of the system. The response time
will be tested and upgrade until it has reach the satisfaction of end-user. Besides, graphical
user interface will be tested until it is user friendly for end-user. Table in the next page will be
used to gather feedback from end users that involved in the testing. Testers just have to tick in
the column for what they feel and lastly give feedback if necessary. TBD in the table stand
for To Be Determine.
User Acceptance Testing

Tester Name: TBD
Date: TBD
Criteria Strongly Disagree Neither Agree Strongly
Disagree Agree
The system has met all TBD TBD TBD TBD TBD
of your requirement
The graphical user TBD TBD TBD TBD TBD
interface have attracted
you
The system is user TBD TBD TBD TBD TBD
friendly
The system response TBD TBD TBD TBD TBD
time is fast
There is no doubt in TBD TBD TBD TBD TBD
using the system
Feedback
TBD
Table 5: User Acceptance Testing form source: Self-make

3.2.4 Defect Tracking

Defect tracking is a process of finding defects in the system by doing system testing or
reviewing users feedback (TutorialsPoint, 2013). A new update version of the system will be
developed after a defect has been found in the system.
The information of founded defect will first be capture and documented with description and
screenshots to capture the vital information about the problem. For example, reservation list
does not provide correct reservation information for user using Kit-Kat version of android.
The problem will be described clearly and screenshots and put it into document. After that,
the problem will be prioritized and scheduled to be fixed. After fixing it, developer will test
the new version and document it to ensure the problem has been fixed before release to the
public.
3.2.5 System Testing

According to Techopedia, system testing is a testing phase where the whole system is tested
in difference environment (Techopedia, 2013). The purpose of the system testing is to test
the behaviour of the final system in different environment to ensure the system has met all the
requirements in the testing phase. Android is an open source operating system. Difference
brand of phone like Samsung and HTC has its own developed android operating system.
Thus, developer will first test Restaurant Directory and Food Reservation system in different
brand of android phones which is Samsung, HTC, Huawei and Lenovo and more but with the
same version of android operating system which is Kit Kat to ensure the system could work
in difference brand of phone. Then, the system will be tested in difference brand of phone and
difference android version to ensure the system could run in difference version. When an
error has occurred in system testing, developer has to describe and screenshot the error and
document it. After that, developer will solve the error and test the system again.

4.0 Estimation
This topic will be discussing estimation of the size and cost of the project to produce a system
that are efficiency and effectiveness. The project team will be using Function Point Analysis
to predict the time needed, effort needed, cost and size for Restaurant Directory and Food
Reservation system.
4.1 UFP Calculation Form

Unadjusted Functional Point (UFP) Calculation Form will be used to calculate the
Unadjusted Function Points (UFP) by counting the number of user input, user output, user
queries, logical files and interfaces. Simple, Average and Complex will be the used to
classified the complex level of the function and weight will be assigned to each of it. the User
Input will be the total input that will be insert by user in the system. For example, login page
will consist of two simple login input. User Output will be the total output that will be display
to user. For instances, four simple restaurant information will be display to user after user has
chosen a restaurant. User Queries will be the total queries that has been used inside the
system. Logical Files is the file that store permanent data for the system. For example, user
account is a simple file that will be stored for the system. Interfaces will be containing the
number of external system used for the system. The next table will be showing UFP
calculation form.

Complexity Level Total

Simple Average Complex FP
Software
System Weighted Weighted Weighted
Component Count Factor Points Count Factor Points Count Factor Points
s
C= I=GX
A B D E F=DXE G H
AXB H
User Input
7 3 21 12 4 48 0 6 0 69
User Output
13 4 52 15 5 75 0 7 0 127
User
Queries 10 3 30 5 4 20 1 6 6 50
Logical
Files 8 7 56 2 10 20 0 15 0 76
Interfaces
0 5 0 0 7 0 0 10 0 0
Total FP 322
Table 6: Unadjusted Function Points(UFP) Calculation Form)

4.2 RCAF
Relative Complexity Adjustment Factor (RCAF) is used to determine the technical
complexity factor (TCF). 14 complexity characteristics of Restaurant Directory and Food
Reservation system will be listed at the below table. Grade 0 to 5 will be assign to the 14
characteristics. 0 will be no complexity and 5 means very complex.
No
No Subject Grade Grade
.
1 Requirement for reliable backup and recovery 0 1 2 3 4 5
2 Requirement for data communication 0 1 2 3 4 5
3 Extent of distributed processing 0 1 2 3 4 5
4 Performance requirements 0 1 2 3 4 5
5 Expected operational environment 0 1 2 3 4 5
6 Extent of online data entries 0 1 2 3 4 5
7 Extent of multi-screen or multi-operation online data input 0 1 2 3 4 5
8 Extent of online updating of master files 0 1 2 3 4 5
9 Extent of complex inputs, outputs, online queries and files 0 1 2 3 4 5
10 Extent of complex data processing 0 1 2 3 4 5
11 Extent that currently developed code can be designed for reuse 0 1 2 3 4 5
12 Extent of conversion and installation included in the design 0 1 2 3 4 5
Extent of multiple installations in an organization and variety
13 0 1 2 3 4 5
of customer organizations
14 Extent of change and focus on ease of use 0 1 2 3 4 5
TOTAL RCAF 43
Table 7: Relative Complexity Adjustment Factor(RCAF) Source : Self-make

4.3 Technical Complexity Factor

TCF = 0.65 + (0.01 x RCAF)
The above formula will be used to calculate technical complexity factor. RCAF value will be
getting from the total of RCAF table. Below is the TCF value that has been calculated.
TCF = 0.65 + (0.01 x 43)
= 46.78487
From the above calculation, the estimated TCF is 46.78487.
4.4 Functional Point

FP = CFP * TCF
= 322 * 1.08
= 347.76
Above is the formula that used to calculate functional point. CFP value will be getting from
the total of UFC table. TCF is Technical Complexity Factor and which has been calculated in
title 4.3. The calculated value for functional point is 347.76.

4.5 Size of Product

LOC = AVC * FP
The size of product will be determined by line of code. The formula above is used to
calculate line of code. AVC stands for average lines of codes and FP stands for Functional
Point. AVC will be calculated based on the language that has been use. The language that will
be used to develop the system is Java and SQL. Java is estimated to has an average of 53 line
of codes and SQL has an average of 21 line of codes. Thus, both of the average will be add
together and divide by two to calculate the average lines of codes for the system. Then the
calculated AVC will be used to calculate LOC. Below is the calculation for calculating LOC.
AVC (Average lines of codes) = (53 + 21) / 2
= 37
LOC = 37 * 347.76
= 12867.12
The above showed that the estimated number for Line Of Code will be 12867. LOC will be
convert to KLOC which is Kilo Line of Codes so that it could be used in calculating effort
needed. Converting LOC to KLOC would give a value of 12.86712 KLOC.

4.6 Effort
Effort = 3.2 * (KLOC) ^1.05
Above is the formula that will be used to estimate effort needed for the system. The KLOC
value is the value that has been calculated in tittle 4.5. Below is the calculation for the
formula.
1.05
Effort = 3.2 * (12.86712)
= 46.78487
According to the above calculation, the estimated effort needed to complete the project is
46.79.
4.7 Schedule
1/ 3
Schedule = 3.0 * (effort month )
Above is the formula to estimate the time needed for the system. Effort month value will be
getting from tittle 4.6. Below is the calculation for the formula.
1 /3
Schedule = 3.0 * (46.78487)
= 3.0 * 3.9017
= 10.80993453
As the calculation above, the estimated time needed to finish the project is around ten
months.
4.8 Cost
Cost is calculated based on the number lines of codes (LOC),it is assumed that RM 1 is
charged for every LOC. Therefore, the estimated cost for this project is RM 12867.12.

5.0 Software Quality Assurance Plan (SQAP)

This document will only describe two topics of SQAP which is Purpose and Scope of SQAP.
The other topic will be further explaining in the appendix.
5.1 Purpose
The purpose of Software Quality Assurance Plan is to define Restaurant Directory and Food
Reservation System Software Quality Assurance (SQA) organization, tasks and
responsibilities. Reference documents and guidelines for SQA activities will also be provided
to ensure that the system met the requirements. Moreover, the system will be reviewed with
provided standards practices and conventions used in carrying out SQA activities to ensure
the quality of the system. Tools and methodologies will also be described in SQA to help in
developing the system.
5.2 Scope
The scope of SQAP is to covers Restaurant Directory and Food Reservation System all
procedures, techniques and tools to be used for quality assurance for this project. SQA
activities will be planned and performed for the system. Besides, activities process and work
product will be review and audit. The goal of SQA is to ensure that the system has met all the
requirement that has been stated in the first phases of waterfall methodology.

6.0 Software Metrics

6.1 Performance
Stress testing is one of the software metric used to determine the effectiveness under
unfavourable conditions (Rouse, 2014). Stress testing will be used to measure the response
time of the system. It has been chosen to measure performance because Restaurant Directory
and Food Reservation system is a system that will be used by a lot of users at the same time.
Many users could access database in the server at the same time. Thus, the performance of
the response time and the server is important for the system.
The testing will be done for each function of the system. The testing begins with 100
concurrent users using a function of the system. The result of the response time will be
recorded. Besides, the server usage of CPU and memory will also be recorded. Then the
number of concurrent users move up to 150 for the testing. The result of the testing will also
be recorded. The number of users will be increasing by 50 users until the system response
time has exceeded 5 second. The higher number of users with response time less than 5
second, the higher the performance of the system. The lower the usage for CPU and memory
of the server, the better the performance for the system. Below is the sample table that used to
record result of the testing. Developer could improve and upgrade the system by referring the
data in the table below in the maintenance phase of waterfall model. TBD stands for To be
Determine.
Number of Users
100 150 200
Software
CPU
System Response Memory Response CPU Memory Response CPU Memory
function Usag
Time Usage Time Usage Usage Time Usage Usage
e
(s) (%) (s) (%) (%) (s) (%) (%)
(%)
Search
TBD TBD TBD TBD TBD TBD TBD TBD TBD
Restaurant
Display
TBD TBD TBD TBD TBD TBD TBD TBD TBD
Restaurants
Table 8:Sample of Performance software metric result Source: Self-make


6.2 Maintainability
Maintainability of the system will be measure by complexity of the system and coupling of
the system. Complexity and coupling is chosen for measurement because the system is
developed using Java and Object Oriented Programming. The more complexity of coding, the
harder for developer to read and understand the object oriented flow. Line of code will be
calculated after the system has finished developed. Developer will calculate the total line of
code used to develop the system. The higher number of line of code means the more
complexity of the system.
Figure 2: Formula for calculate high coupling Source: (Greef, 2015)
Moreover, high coupling between classes or package in object oriented will also affect the
understanding of new developer. Above is the formula that will be used to measure coupling
of the system. I stand for Instability which is resilience to change, metric between 0 and 1
where 0 refer to stable. Ce stands for Efferent Coupling which is the amount of dependencies
of class. Ca stands for Afferent Coupling which is amount of other packages depending on
class.

6.3 Usability
Task time will be used to measure the efficiency and productivity of the system. 100 users
will be invited to test the system usability. The time taken for a user to complete a single task
will be recorded in seconds. All task or function of the system will be tested and recorded.
For example, the time taken for a user to complete registration with the system will be
recorded. The shorter the time taken to finish a task, the higher the usability of the system.
Moreover, users will have to give satisfaction level for each task that has been done based on
user experience. The satisfaction level will be determined by rating 1 to 5. The lower the
rating means the lower satisfaction of the users. Feedback column will also be provided to
collect more information to determine the usability. Below is the sample table that record
testing result. TBD stands for To be Determine.
Usability testing
Tester Name: TBD
Date: TBD
Software function Time taken to Satisfaction Feedback
complete a task level
(s) (1-5)
Register TBD TBD TBD
Login TBD TBD TBD
Search restaurant TBD TBD TBD
Table 9: Sample of Usability testing table

7.0 Conclusion and Recommendation
Restaurant Directory and Food Reservation system is an android mobile application system
that could let user book table and order food for the specific restaurant. It will be following
the phases of waterfall methodology that has been explain and described in this document.
Moreover, the three types of quality attributes which is performance, maintainability and
usability and five types of quality assurance process of the system has been well defined and
explained in this document to ensure the quality of the system. Estimation for effort, schedule
and cost of the system also has been calculated and documented. Software Quality Assurance
Plan (SQAP) and software metrics also has been discussed in this document.
7.1 Recommendation
To provide a high quality of system, the team must have a software quality engineer that has a
wide understanding of the system and software quality standards. It is required for software
quality engineer to solve systems quality problem efficiently. Besides, the team must be
following the methodology phases strictly because it is a waterfall methodology where there
should not be any requirements changes after the first phase. Moreover, the project team
should have more software metrics to fully measure the quality attribute of the system. This is
to ensure the quality of the system from every perspective of the system is high. Testers will
also have to work hard to test the whole system to ensure the system would not go wrong
after launched to the market.

8.0 References
References
ADVOSS, 2013. ADVOSS. [Online]
Available at: http://www.advoss.com/software-quality-attributes-maintainability.html
[Accessed 5 May 2016].
Andy, 2016. Software Testing Help. [Online]
Available at: http://www.softwaretestinghelp.com/what-are-the-quality-attributes/
Bordo, V., [No Date]. DEVELOPMENTOR. [Online]
Available at: https://www.develop.com/useracceptancetests
[Accessed 23 November 2015].
Dobb, D., 2011. Software Development magazine. Dr. Dobb's Journal, 1(12), p. 112.
Greef, D. d., 2015. InShare. [Online]
Available at: http://www.slideshare.net/dennisdegreef/measuring-maintainability-software-
metrics-explained
Rouse, M., [No Date]. TechTarget. [Online]
Available at: http://searchsoftwarequality.techtarget.com/definition/unit-testing
Rouse, M., [No Date]. TechTarget. [Online]
Available at: http://searchsoftwarequality.techtarget.com/definition/integration-testing
Rouse, M., 2014. TechTarget. [Online]
Available at: http://searchsoftwarequality.techtarget.com/definition/stress-testing
SotfwareArchitecture, 2013. Quality Attributes. [Online]
Available at: http://www.softwarearchitectures.com/qa.html
Tan, J., 2013. HNComputing. [Online]
Available at: http://www.sqa.org.uk/e-learning/SDPL03CD/page_16.htm
Techopedia, 2013. Techopedia. [Online]
Available at: https://www.techopedia.com/definition/22445/system-testing
Tutorialspoint, 2013. Tutorialspoint. [Online]
Available at: http://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

TutorialsPoint, 2013. Tutorialspoint. [Online]

Available at:
http://www.tutorialspoint.com/software_testing_dictionary/defect_logging_and_tracking.htm

SQE

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

SQE

Caricato da

Copyright:

Formati disponibili

SOFTWARE QUALITY ENGINEERING INDIVIDUAL ASSIGNMENT

PHAN YONG SHIN TP 027858 1

PHAN YONG SHIN TP 027858 2

PHAN YONG SHIN TP 027858 3

1.2 Purpose and Scope of the system

PHAN YONG SHIN TP 027858 4

Figure 1: Waterfall Model phases source: (TutorialsPoint, 2013)

PHAN YONG SHIN TP 027858 5

PHAN YONG SHIN TP 027858 6

PHAN YONG SHIN TP 027858 7

3.0 Quality Assurance Process

3.1 Software Quality Attributes

Performance attribute is an indication of the responsiveness of a system execute any process

PHAN YONG SHIN TP 027858 8

PHAN YONG SHIN TP 027858 9

3.2 Five Types of Quality Assurance Process

Policies and standard for development tools

Version Implemented Revision Approved Approval Description of

Table 2:Summary of system version details source: Self-make

PHAN YONG SHIN TP 027858 10

3.2.2 Verification and Validation

PHAN YONG SHIN TP 027858 11

3.2.3 Types of Testing

PHAN YONG SHIN TP 027858 12

PHAN YONG SHIN TP 027858 13

PHAN YONG SHIN TP 027858 14

nothing and close the message box

PHAN YONG SHIN TP 027858 15

PHAN YONG SHIN TP 027858 16

System Name: Restaurant Directory and food reservation application

PHAN YONG SHIN TP 027858 17

User Acceptance Testing

User Acceptance Testing

PHAN YONG SHIN TP 027858 18

3.2.4 Defect Tracking

3.2.5 System Testing

PHAN YONG SHIN TP 027858 19

4.1 UFP Calculation Form

PHAN YONG SHIN TP 027858 20

Complexity Level Total

PHAN YONG SHIN TP 027858 21

PHAN YONG SHIN TP 027858 22

4.3 Technical Complexity Factor

TCF = 0.65 + (0.01 x 43)

From the above calculation, the estimated TCF is 46.78487.

4.4 Functional Point

title 4.3. The calculated value for functional point is 347.76.

PHAN YONG SHIN TP 027858 23

4.5 Size of Product

AVC (Average lines of codes) = (53 + 21) / 2

needed. Converting LOC to KLOC would give a value of 12.86712 KLOC.

PHAN YONG SHIN TP 027858 24

PHAN YONG SHIN TP 027858 25

5.0 Software Quality Assurance Plan (SQAP)

PHAN YONG SHIN TP 027858 26

6.0 Software Metrics

PHAN YONG SHIN TP 027858 27

PHAN YONG SHIN TP 027858 28

Figure 2: Formula for calculate high coupling Source: (Greef, 2015)

PHAN YONG SHIN TP 027858 29

PHAN YONG SHIN TP 027858 30

7.0 Conclusion and Recommendation

PHAN YONG SHIN TP 027858 31