(OCMS) Final Project Documentation Complete CC

CS- UOG - Project Coordination Office Version: 1.
0
Final Project Date: May 15, 2019
Department of Computer Science
University of Gujrat, Lahore Sub Campus
ONLINE CAR MODIFICATION SYSTEM
Session: BSCS Fall 2015-2019
Project Supervisor: Haroon Shahzad
Submitted By:
Abram JOhn 15111519-063
Hamza Asghar 15111519-084
Shehroz Akhtar 15111519-047
Usama Bin Munir 15111519-155
Department of Computer Science,

University of Gujrat, Lahore Sub Campus.
© Computer Science, University of Gujrat, Lahore Sub Campus Page 1

CS- UOG - Project Coordination Office Version: 1.0
STATEMENT OF SUBMISSION
This is certify that Abram John Roll No. 15111519-063 , Hamza Asghar Roll No.
15111519-084 , Shehroz Akhtar Roll No. 15111519-047 and Usama bin Munir Roll
No.15111519-155 has successfully completed the final year project named as ONLINE
CAR MODIFICATION SYSTEM at the Department of Computer Science, University
of Gujrat, Lahore Sub Campus to fulfill the requirement of the degree of BS Computer
Science.
______________________ _____________________
Project Supervisor Project Coordination Office
Faculty of CS&IT -UOG
______________________
Head of the Department

Acknowledgement
We truly acknowledge the cooperation and help make by Mr. Haroon Shahzad, Head of
Department, Department of Computer Science, University of Gujrat, Lahore Sub
Campus. He has been a constant source of guidance throughout the course of this project.
We would also like to thank Mr. Haroon Shahzad for his help and guidance throughout
this project. We are also thankful to our friends and families whose silent support led us
to complete our project.
1- Mubasher Hussain.
Date: December 5, 2018
Abstract

The project Online Car Modification System is a garage related website that makes
users to get virtual idea of car modification online. The basic purpose of this website is
welfare of human being and for humanity. OCMS provide communication between
garage, user and system. In this website a user will visit and select his car and its model,
after selecting the car our website will provide user modification parts afterwards user
will select parts on need based. There will be option for user whether he want to buy the
parts or he wanted it to install by the garage. User will require a login for doing these
options that contains user details so that it can be ease at Invoice generation. Our main
purpose to develop this website is to save time and reduce work load of human body and
more importantly to serve humanity. If user buy the parts online he will pay via cash on
delivery and if he want it to be install through garage then he will select team for doing
the task and will get an appointment. Online Car Modification System is pleased to
offer attentive service that meets all your needs.
TABLE OF CONTENTS

CHAPTER 1: PROJECT FEASIBILITY REPORT.....................................................1

1.1. INTRODUCTION.....................................................................................................2
1.2. PROJECT/PRODUCT FEASIBILITY REPORT.................................................................2
1.2.1. Technical Feasibility.........................................................................................2
1.2.2. Operational Feasibility.....................................................................................3
1.2.3. Economic Feasibility.........................................................................................3
1.2.4. Schedule Feasibility..........................................................................................3
1.2.5. Specification Feasibility....................................................................................3
1.2.6. Information Feasibility......................................................................................3
1.2.7. Motivational Feasibility....................................................................................3
1.2.8. Legal & Ethical Feasibility...............................................................................3
1.3. PROJECT/PRODUCT SCOPE........................................................................................3
1.4. PROJECT/PRODUCT COSTING....................................................................................4
1.4.1. Project Cost Estimation by Function Point Analysis........................................4
1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)...6
1.5. TASK DEPENDENCY TABLE.......................................................................................7
1.6. CPM - CRITICAL PATH METHOD..............................................................................8
1.7. GANTT CHART...........................................................................................................9
1.8. INTRODUCTION TO TEAM MEMBER AND THEIR SKILL SET......................................10

1.9. TASK AND MEMBER ASSIGNMENT TABLE..............................................................10
1.10. TOOLS AND TECHNOLOGY WITH REASONING.......................................................12
1.11. VISION DOCUMENT...............................................................................................12
1.12. RISK LIST..............................................................................................................13
1.13. PRODUCT FEATURES/ PRODUCT DECOMPOSITION................................................13
CHAPTER 2: SOFTWARE REQUIREMENT SPECIFICATION (FOR OBJECT
ORIENTED APPROACH).............................................................................................14
2.1 INTRODUCTION:........................................................................................................15
2.1.1 Systems Specifications................................................................................15
3.1.2. Identifying External Entities........................................................................17
2.1.3. Context Level Data Flow Diagram:...........................................................18
2.1.4. Capture "shall" Statements:.......................................................................18
2.1.5. Allocate Requirements:..............................................................................19
2.1.6. Prioritize Requirements:.............................................................................20
2.1.7. Requirements Trace-ability Matrix:...........................................................22
2.2.10. High Level Usecase Diagram:......................................................................23
2.2.11. Analysis Level Use case Diagram:................................................................24
CHAPTER 3: DESIGN DOCUMENT (FOR OBJECT ORIENTED APPROACH)
...........................................................................................................................................26
3.1. INTRODUCTION:.......................................................................................................27
3.2. DOMAIN MODEL......................................................................................................27
3.3. SYSTEM SEQUENCE DIAGRAM................................................................................28
3.4. SEQUENCE DIAGRAM..............................................................................................29
3.5. COLLABORATION DIAGRAM....................................................................................30

3.6. OPERATION CONTRACTS.........................................................................................31

3.7. DESIGN CLASS DIAGRAM........................................................................................34
3.8. STATE CHART DIAGRAM..........................................................................................35
3.9. DATA MODEL..........................................................................................................36
CHAPTER 4: USER INTERFACE DESIGN...............................................................37
4.1. INTRODUCTION........................................................................................................38
4.2. SITE MAPS...............................................................................................................38
4.3. STORY BOARDS.......................................................................................................44
4.4. NAVIGATIONAL MAPS:............................................................................................44
4.5 TRACE-ABILITY MATRIX..........................................................................................44
CHAPTER 5: SOFTWARE TESTING.........................................................................47
5.1 INTRODUCTION:........................................................................................................48
5.2. TEST PLAN...............................................................................................................48
7.2.1. Purpose............................................................................................................48
5.2.2. Outline.............................................................................................................48
5.3. TEST DESIGN SPECIFICATION...................................................................................53
5.3.1. Purpose............................................................................................................53
5.3.2. Outline.............................................................................................................53
5.4. TEST CASE SPECIFICATION.....................................................................................57
5.4.1. Purpose............................................................................................................57
5.4.2. Outline.............................................................................................................57
5.5. TEST PROCEDURE SPECIFICATION............................................................................59
5.5.1. Purpose............................................................................................................59
5.5.2 Outline..............................................................................................................59
5.6. TEST ITEM TRANSMITTAL REPORT...........................................................................61
5.6.1. Purpose............................................................................................................61
5.6.2. Outline.............................................................................................................61
5.7. TEST LOG.................................................................................................................62
5.7.1. Purpose............................................................................................................62
5.7.2. Outline.............................................................................................................62
5.8. TEST INCIDENT REPORT...........................................................................................63
5.8.1. Purpose............................................................................................................63
5.8.2. Outline.............................................................................................................63
5.9. TEST SUMMARY REPORT.........................................................................................63
5.9.1. Purpose............................................................................................................63
5.9.2. Outline.............................................................................................................63


Chapter 1: Project Feasibility Report

1.1. Introduction
First deliverable is all about planning and scheduling of project. This deliverable must
contain following artifacts:
a. Project Feasibility
b. Project Scope
c. Project Costing
d. Task Dependency Table
e. Critical Path Method Analysis (CPM Analysis)
f. Gantt Chart
g. Introduction to team members
h. Tasks and member assignment table
i. Tools and Technologies
j. Vision Document
k. Risk List
l. Product Features
1.2. Project/Product Feasibility Report

The project to be developed will be helpful for the user because it will save the time and
money of the user and user can get the virtual idea of his automobile that how his
automobile will look like after modification of parts that he want to buy and to be
installed. As well as user can get idea about the cost of the modification.
The project is useful for the garage in billing, product lists bought by users, mechanic
team selection.
There are many types of feasibilities:
 Technical
 Operational
 Economic
 Schedule
 Specification
 Information
 Motivational
 Legal and Ethical
1.2.1. Technical Feasibility

We develop a system where we have three actors which are user, admin, and mechanics.
In addition user will visit the website and search for his desire parts accordingly.
Afterwards the parts are selected user will have two possibilities whether he want to
install the selected parts from the garage or to buy online.
In between the process off selection and buying admin panel will supervise all the
activities.

1.2.2. Operational Feasibility
Operational feasibility deals with the problems arises in the project if any type of problem
arises then our admin panel will solve it.
For example if user selects five parts and four parts are added to cart but one part remains
the admin panel will show a popup asking user whether he want to add fifth item in cart
or not.
1.2.3. Economic Feasibility
The project could be divided into two parts cost estimation and benefit estimation.
Cost estimation for project development is round about 10000 and maintenance cost is
about 5000 approx.
We should come around the benefits of the project which are 24/7 service, time saving,
Minimizing workload, high quality product, and virtual idea of automobile.
1.2.4. Schedule Feasibility
Time is very important factor for the project. Project feasibility report has been done in
two weeks. System requirement specification has been done in three weeks. Design
documents has been done in four weeks. Coding has been done in seventeen weeks.
Testing has been done in one week.
1.2.5. Specification Feasibility
User must be login and logout successfully. Any new user could easily sign up and then
should be able to sign in after becoming a member.
1.2.6. Information Feasibility
Project is developed in time as define before the project is approximately complete in 8
months. It also fulfill the requirements of user according to its need if any problem will
be occur then our admin team resolve it. After the validation of information system will
allow the user to select part and to buy or install it from the Garage.
1.2.7. Motivational Feasibility
Project is about to decrease the time waste and money of the people. Buy not going to
Garage and get the idea of how their car look like. Our website will motivate people for
ease of modification and access all functionality of website easily.
1.2.8. Legal & Ethical Feasibility

Project is completely legal and ethical as it is helpful to common people. People use our
website to modify the car and to buy parts.
1.3. Project/Product Scope

Online car modification system will facilitate the user to buy and install parts for his
automobile. The following are the main function of online car modification system.
 User registration.
 User login.
 System Admin.

1.4. Project/Product Costing
Sr No. Name of Activities Resources Cost Rate
1 Detail study of requirements. Study via internet Self-development
and brain storming. no cost.
2 Proposal. Mr. Haroon Self-development

Shahzad. no cost.
3 Requirement Analysis. Proof reading, Self-development

Analyzing through no cost.
Dreamweaver.
4 Web Interface design. HTML, CSS, Self-development
JavaScript, no cost.
Bootstrap.
5 Web Development. HTML, CSS, Self-development
JavaScript, no cost.
Bootstrap, PHP
XAMPP.
6 Testing and Refinement. Website and Self-development
manual testing. no cost.
7 Finalization. QA. Self-development

no cost.
1.4.1. Project Cost Estimation by Function Point Analysis
Functional Low Values Average High Values FP Counts

Units Values
External Input 0*3=0 0*4=0 6*6=36 36
External 0*4=0 3*5=15 0*7=0 15
Output
User Inquiries 1*3=3 0*4=0 0*6=0 3
Internal 3*7=21 0*10=0 0*15=0 21
Logical Files
External 2*5=10 0*7=0 0*10=0 10
Interface Files
TotalCount - - - 85

Complexity Adjustment Factors:
Factor Value (0-5)

Data Communication 3
Distributed Data Processing 4
Performance 4
Heavily Used Configuration 2
Transaction Rate 2
On-Line Data Entry 2
End User Efficiency 5
On-Line update 4
Complex Processing 3
Reusability 3
Installation Ease 4
Operational Ease 4
Multiple Sites 5
Facilitate Change 4
Total = ∑Fi 48
External Inputs 2*4=8

External Output 2*5=10
Total 8+10=18
FP est. = Count Total * [0.65 + 0.01 * (Fi)]
Finally, Total Project Cost and Total Project Effort are calculated given the average
productivity parameter for the system.
The formulae are given as follows:
Cost / FP = labor rate / productivity parameter
Total Project Cost = FP est. * (cost / FP)
Total Estimated Effort = FP est. / productivity parameter

FP est. = Count Total * [0.65 + 0.01 * (Fi)]
FP est. = 18 * [0.65 + 0.01 * 48]
FP est. = 20.34
Cost / FP = 500$/10$ = 50
Total Project Cost = 20.34 * 50 = 1017
Total Estimated Effort = 20.34 / 10 = 2.034
1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)

Boehm's COCOMO model is one of the mostly used models commercially. The first
version of the model delivered in 1981 and COCOMO II is available now. COCOMO 81
is a model that allows one to estimate the cost, effort, and schedule when planning a new
software development activity, according to software development practices that were
commonly used in the 1970s through the 1980s. It exists in three forms, each one offering
greater detail and accuracy the further along one is in the project planning and design
process. Listed by increasing fidelity, these forms are called Basic, Intermediate, and
Detailed COCOMO. However, only the Intermediate form has been implemented by
USC in a calibrated software tool.
Three levels:
Modes of COCOMO:
Parameters Organic Semi Embedded
Size 2-50 KLOC 50-300 KLOC 300KLOC or above
Team Small Medium Large
Developer Experienced Average Little Experience
Experience Developer
Environment Familiar Less Familiar Changed
Innovation Little Medium Major Innovation
Deadline Flexible Medium Tight deadline
Parameters of Different Modes:

Modes A B C D
Organic 2.4 1.05 2.5 0.38
Semi- 3.0 1.12 2.5 0.35
Detached
Embed 3.6 1.20 25 0.32
Effort:
E = a (KLOC) ^ b Person/Month
E = 2.4(8) ^ 1.05
E = 21.4 Person/Month

Developer Time:
Dev Time = c (Effort) ^ d Months
Dev Time = 2.5(21.4) ^ 0.38 Months
Dev Time = 8.00 Months
Average Staff Size = Effort/Dev Time

Average Staff Size = 21.4/8
Average Staff Size = 2.675
Productivity = KLOC/Effort
Productivity = 8/21.4
Productivity = 0.373
1.5. Task Dependency Table
Sr. No. Activity Predecessor Duration(weeks)

A Project Activity ---- 2
B Project Planning A 1
C Project A,B 4
Documentation
D Project Design C 4
E Coding D,B,E 17
F Project Testing E 1
G Project Delivery F 1
1.6. CPM - Critical Path Method

Network Diagram for the above-mentioned activities
Duratio
Activity ES EF LS LF TS FS
n
A 5 0 5 0 5 0 0
B 3 0 3 3 6 3 2
C 8 5 13 5 13 0 0
D 7 5 12 6 13 1 1
E 7 0 7 6 13 6 6
F 4 13 17 13 17 0 0
G 5 17 22 17 13 0 0
The parameters and slacks are calculated as follows:
The critical path is:

A, C, F, G
1.7. Gantt chart
Task Name Start Week Week Duration

Project Activities 1 2
Planning 3 1
Documentation 4 4
Designing 8 4
Coding 12 17
Testing 30 1
Delivery 31 1
Online Car Modification System
Project Activities
Planning
Documentation
Designing
Coding
Testing
Delivery
1 6 11 16 21 26 31
Start Week Week Duration End Week
1.8. Introduction to Team member and their skill set
Members Name Skill Set Tasks

Abram John HTML, Designing, Designing, Coding,
Validation Diagrams in Documentation
Hamza Asghar HTML, PHP Structure and layout, Data
base and Implementation
Shehroz Akhtar Documentation, Testing, Testing Planning
Validation
Usama Bin Munir Documentation, Designing Interface Testing, Structure

and Layout

1.9. Task and Member Assignment Table
Task Duration Dependencies Members

Final Proposal 2 weeks M1 , M2
SRS documentation 1 week T1 M4, M3
Data collection 4 week T1 ,T2 M4 , M3
Web design 4 week T1 ,T2 , T3 M1 , M2, M3, M4
Database 17 week T1 T2 T3 T4 M2
Back end coding 1 week T1, T2, T3 T4 T5 M2
Final 1 week T1 ,T2 ,T3 ,T4 ,T5 ,T6 M1 , M3
documentation T7 T8
Task durations and dependencies

Activity Bar Chart:
Allocation of People to Activities:
Task Engineer
T1- Final Proposal Abram, Hamza
T2- SRS documentation Shehroz, Usama
T3- Data collection Shehroz, Usama
T4- Web design Hamza
T5- frontend coding Abram, Usama
T6- Back end coding Hamza, Shehroz
T7- Final Documentation Abram, Usama
T8- project viva Abram, Hamza, Shehroz, Usama
Staff Allocation:

1.10. Tools and Technology with reasoning
 Tool code igniter is used. This is powerful PHP framework.
 PHP is used for backend because PHP is the server scripting language. It provides
 The better security than other
 HTML, CSS, Bootstrap, Javascript and Jquery is used for the frontend.
 Javascript and Jquery is used for the validation.
1.11. Vision Document

Vision behind this project is to provide a platform which fulfills all requirements of car
enthusiast at one place. In this era of modern technology everyone wants to save time and
money, for this purpose our development team is going to provide a platform in which a
person can get virtual idea of car modification, and can buy modification parts at the
same time. For the first time we are providing our customer with a very helpful option of
getting their car modified and being delivered at their doorsteps by our garage.
We are also providing our customers with a choice of choosing their desired team of
mechanics available for the car modification. Our customer can choose mechanic team on
the basis of their past work and success percentage being displayed on a separate section
in our website. Our basis goal is to facilitate public, on other hand it will reduce time and
garage runaway issues.

1.12. Risk List
 Privacy and Security break.
 Maintaining the status.
 User try to enter wrong information when signup.
 User try to book an available mechanic team and time slot.
 Poorly designed interface which don’t attracts the user.
1.13. Product Features/ Product Decomposition

 User login.
 User search parts category.
 Book his mechanic team and time slot.
 Admin/Sub-Admins logs in and checks for the booked slots and assign task to
mechanic team.
 Admin supervise all the activities of sub-admins and user.
 Admin/Sub-Admin or user can cancel appointment any time.

Chapter 2: Software Requirement Specification (For Object Oriented
Approach)
2.1 Introduction:
Online Car Modification System is a basically Garage website. Which is user friendly
website. The purpose of this website to provide easiness work to the garage and provide

easy and good service to customer. This website provide an idea to the customers, while
sitting at home by visit on website.
The main purpose of this website is to provide the automatically work as compared to
manually. The customers can be able to purchase the parts and modify his car by register
himself on the website. There is fully option for customer to add or remove things
according to his requirements.
Our website deal with good staff, modify parts and E-commerce.
2.1.1 Systems Specifications

The following are the clauses that must be included while describing the system
specifications.
Introduction
The website work very efficient and user friendly. This website shows the latest and new
parts and show new upgrades coming in 21 st century. But our Garage provide the all
facility to the customer all type of parts according to his requirement. And give 5 star
service to the customer. Online car modification system is the website of the garage
which provides online car modification instead of visiting garage. The purpose of this
website is to provide virtual idea and save time of the user. The aim of this website to
provide easy way for the customer so he can get idea of his car or he could buy the parts
according to his desire in fair price. This website is helpful in such cases when user
cannot reach to the garage due to his busy schedule.
Existing System
Some customers are very busy in her business, office or organization they never visit to
garage to upgrade his car. Because by the shortage of time for customer our website make
easy path to the customers. Online car modification system save the time, cost and money
of the customer. By the one click on button customer can order our system by sitting at
his home. So this purpose is basically for easy and comfort and provide good facility to
the customers.
Organizational Chart:

OCMS
User
Sign Up
Login
Select
Car/jeep
Select
Parts
Buy Install
Parts Parts
Select
Team
Get
Invoice
Scope of the System

The scope of the system are:

 Customer registration.
 Garage overview.
 Check the parts and automobile.
 Check the price of items and check available team for working.
 Take record of his customer in database
 Provide security
 Billing and payment
 Notify the admin and customer of order
Summary of Requirements: (Initial Requirements)

The requirements that considered are as follows:
1. Online car modification system is a garage which deal with customers online.
And show all available virtual idea to the customer 24 hours any time.
2. This garage is user friendly but there are some important rule of this garage which
must be follow the customers according to our requirement.
3. Customer visit the garage and register our garage. After this it can fill different
options for its registration like Name, category, car, password etc.
4. After this phase customer database save our server and its data show admin what
customer want. Customer estimate the price the price of parts and automobiles.
Customers select the car type and select the parts by click on button.
5. The next phase is to inform the customer the cost of its modification. If customer
is satisfied he/she select it and click on “the team selection part” for its
satisfaction and for working.
6. After this garage show the require days for working and show its good team for
working the car.
7. Now complete the process and complete the user requirement after this generate
the bill and inform the user to receive his car from garage.
8. User pay the amount according to invoice on cash on delivery while the work is
done completely.
3.1.2. Identifying External Entities

The Identification of External Entities is done in two phases.
a. Over Specify Entities from Abstract:

On the basis of the Abstract, one might identify of online car modification system are:

 Customer
 Admin
 Select Category (Car, Jeep)
 Modification
 Register
 Cash
 Delivery
b. Perform Refinement:
We found the following entities more related to our business logic are:
 Admin
 Customer
 Register
2.1.3. Context Level Data Flow Diagram:
2.1.4. Capture "shall" Statements:
Para Initial Requirements

#
1.0 Customer “shall” visit the website.
1.0 Customer “shall” register himself on website and take order to modify his car.
1.0 Customer “shall” select category and select the car model.
1.0 Admin “shall” sign in and see the order.
1.0 Admin “shall” perform operation CRUD.
2.0 Register user “shall” select and buy parts.
2.0 Register user “shall” select the team.
2.0 Unregister customer “shall” only visit and see parts.
2.0 Database “shall” check the registration of customer and start work his car.
2.0 Customer “shall” login its ID and check the parts and its price online.
3.0 Server “shall” check the validation.
3.0 Garage provide good team and “shall” do work correctly.
3.0 Changing “shall” be apply on cars and modify it according to customer

requirement.
3.0 Invoice “shall” be generated after completing the process.
“Table 2.1: Capture “Shall” Statement”
2.1.5. Allocate Requirements:
Para Initial Requirements Use Case Name

#

1.0 Customer “shall” visit the website. UC_Visit
1.0 Customer “shall” register himself on website and UC_Sign_Up

take order to modify his car.
1.0 Customer “shall” select category and select the UC_Select_Category
car model.
1.0 Admin “shall” sign in and see the order. UC_Login
1.0 Admin “shall” perform operation CRUD. UC_Operation
2.0 Register user “shall” select and buy parts. UC_View_Parts
2.0 Register user “shall” select the team. UC_View_Team
2.0 Unregister customer “shall” only visit and see UC_View_Parts

parts.
2.0 Database “shall” check the registration of UC_Check_Registration
customer and start work his car.
2.0 Customer “shall” login its ID and check the parts UC_Register_View
and its price online.
3.0 Server “shall” check the validation. UC_Validation
3.0 Garage provide good team and “shall” do work UC_Team_Work

correctly.
3.0 Changing “shall” be apply on cars and modify it UC_Update
according to customer requirement.
3.0 Invoice “shall” be generated after completing the UC_Invoice
process..
“Table 2.2: Allocate Requirements”
2.1.6. Prioritize Requirements:
Use
Para Rank Initial Requirements Case Use Case Name
# ID

1.0 Highest Customer “shall” visit the UC_1 UC_Visit
website.
1.0 Highest Customer “shall” register UC_2 UC_Sign_Up

himself on website and take
order to modify his car.
1.0 Highest Admin “shall” sign in and see UC_3 UC_Login

the order.
1.0 Highest Admin “shall” perform UC_4 UC_Operation

operation CRUD.
2.0 Highest Unregister customer “shall” UC_5 UC_View_Parts

only visit and see parts.
2.0 Highest Database “shall” check the UC_6 UC_Check_Registration

registration of customer and
start work his car.
1.0 Medium Customer “shall” select UC_7 UC_Select_Category

category and select the car
model.
2.0 Medium Register user “shall” select and UC_8 UC_View_Parts

buy parts.
2.0 Medium Register user “shall” select the UC_9 UC_View_Team

team.
2.0 Medium Customer “shall” login its ID UC_10 UC_Register_View

and check the parts and its price
online.
3.0 Medium Server “shall” check the UC_11 UC_Validation
validation.
3.0 Medium Invoice “shall” be generated UC_12 UC_Invoice

after completing the process.
3.0 Lowest Garage provide good team and UC_14 UC_Team_Work

“shall” do work correctly.
3.0 Lowest Changing “shall” be apply on UC_15 UC_Update

cars and modify it according to
customer requirement.

“Table 2.3: Priorities Requirements”
2.1.7. Requirements Trace-ability Matrix:
No Para System Specification Text Build Use Case Name Category

. #
1 1.0 Customer “shall” visit the website. B1 UC_Visit Business
2 1.0 Customer “shall” register himself B1 UC_Sign_Up Business

on website and take order to modify
his car.
3 1.0 Customer “shall” select category B1 UC_Select_Category Business

and select the car model.
4 1.0 Admin “shall” sign in and see the B1 UC_Login Business
order.
5 1.0 Admin “shall” perform operation B1 UC_Operation Business

CRUD.
6 2.0 Register user “shall” select and buy B1 UC_View_Parts Business

parts.
7 2.0 Register user “shall” select the B1 UC_View_Team Business

team.
8 2.0 Unregister customer “shall” only B1 UC_View_Parts Business

visit and see parts.
9 2.0 Database “shall” check the B1 UC_Check_Registration Business
registration of customer and start
work his car.
10 2.0 Customer “shall” login its ID and B1 UC_Register_View Business
check the parts and its price online.
11 3.0 Server “shall” check the validation. B1 UC_Validation Business
13 3.0 Garage provide good team and B1 UC_Team_Work Business

14 3.0 Changing “shall” be apply on cars B1 UC_Update Business
and modify it according to customer
requirement.
15 3.0 Invoice “shall” be generate after B1 UC_Invoice Business
completing the process.
“Table 2.4: Requirements Traceability Matrix”
2.2.10. High Level Usecase Diagram:

“Figure 2.3: Analysis Level Use Case Diagram”
2.2.11. Analysis Level Use case Diagram:

“Figure 2.4: Analysis Level Use Case Diagram”

Chapter 3: Design Document (For Object Oriented Approach)

3.1. Introduction:
Third deliverable is all about the software design. In the previous deliverable, analysis of
the system is completed. So we understand the current situation of the problem domain.
Now we are ready to strive for a solution for the problem domain by using object-
oriented approach. Following artifacts must be included in the 3rd deliverable.
1. Domain Model
2. System Sequence Diagram
3. Sequence Diagram
4. Collaboration Diagram
5. Operation Contracts
6. Design Class Diagram
7. State Transition Diagram
8. Data Model
Now we discuss these artifacts one by one as follows:
3.2. Domain Model

3.3. System Sequence Diagram
Admin
User Server Database
Database
Login
Validation
Yes/No
Yes/No
Add sub-Admin
Add Sub-Admin
Data Saved
Sub-Admin Added
Create Data
Create Data
Data Created
Data Created
Read Data
Read Data
Data Read
Data Read
Delete Data
Delete Data
Data Deleted
Data Deleted
Update Data
Update Data
Data Updated
Data Updated

3.4. Sequence Diagram
User
User Server
Database
SignUp
Register Data
Registered
Registered
Sign In
Validation
Yes/No
Yes/No
Select Car/Jeep
Select Car/Jeep
Send Data
Show Data
Select Parts
Select Parts
Get Parts
Get Parts
Buy Parts
Install Parts
Show Team
Team List
Team List
Get Invoice
Show Invoice after being Generated

3.5. Collaboration Diagram
8: siginUp() 8.1: Login()
:SignUp
1: Car selection() 7: Login()

:Select Car/
:User
Jeep
2: Part selection()
3: Buying parts()
:Buy Parts :Select Parts :Login
4: Installing parts()
:Install Parts
5: TeamSelection()
5.1: Login()
:Select Team
6: Getinvoice()
:Generate
Invoice
3.1: Login()

3.6. Operation Contracts
A UML Operation contract identifies system state changes when an operation happens.
Effectively, it will define what each system operation does. An operation is taken from a
system sequence diagram. It is a single event from that diagram. A domain model can be
used to help generate an operation contract.
Register
Name Account Registration (Name, Email, Phone

No, Password)
Responsibilities: Record data
Cross Reference: UC_Sign_Up
Exception: None
Preconditions: 
Database Management System
should be in working condition
 Server availability
Post Conditions: User account was created
Login
Name : Login(Email , Password)
Responsibilities: Verify the users by checks
Cross References: UC_Login
Exceptions: None
Preconditions: 
should be in working conditions
 Server Availability
Post Conditions: User account was updated

Select Car/Jeep
Name Select Car/Jeep (Car Name, Car Model)

Responsibilities: Selection of Car/Jeep
Cross Reference: UC_Select_Car/Jeep
Exception: None
Preconditions: 
Post Conditions: Car/Jeep was selected
Select Parts
Name Select parts(Part Name , Price ,

Specification)
Responsibilities: Selection of parts
Cross Reference: UC_Select_Parts
Exception: None
Preconditions: 
Post Conditions: Parts were Selected

Buy Parts
Name Buy Parts (Cash on delivery)

Responsibilities: Parts buy
Cross Reference: UC_Buy_Parts
Exception: None
Preconditions: 
Post Conditions: User buy parts
Install Parts
Name Install Parts

Responsibilities: To install parts that are selected
Cross Reference: UC_Install_Parts
Exception: None
Preconditions: 
Post Conditions: Parts were installed

Select Team
Name Select Team (Group of teams)

Responsibilities: To install Parts that are selected by user
Cross Reference: UC_Select_Team
Exception: None
Preconditions: 
Post Conditions: Team was selected
Get Invoice
Name Get Invoice(Parts price , Labor cost)

Responsibilities: Generate Invoice
Cross Reference: UC_Get_Invoice
Exception: None
Preconditions: 
Post Conditions: Invoice generated
3.7. Design Class Diagram

….

3.8. State chart diagram
User
Login
Main Menu Select Module
Other Process Session Start
Selected
Processing
Logout

3.9. Data Model
Register
- Email
- Name
- Phone
- Password
Has
Login User
- Email Has
- Name
- Password
Has
Select Car/Jeep
- Model
- Name
Has
Buy Parts Select Parts Install
- Cash on Has Get -Labor cost

- Name
delivery -view selected
- Price
parts
Has
Get Invoice Select Team
Get - User Details Get - Team Name

- Total Cost - No of Members

Chapter 4: User Interface Design

4.1. Introduction
A user friendly interface design is easy to understand and use. It can made easy step to
understand the user requirement. OCMS is also a user friendly website and show easy
interfaces to the user like style, design or buttons etc. It can show better graphics and
pixel to the user which is very important to interact with the website and eyes.
Now, for better interact and visualize the website we use the 4 types of functionality in
our website.
1. Site maps
2. Storyboards
3. Navigational maps
4. Traceability Matrix
4.2. Site Maps

Here, site map is basically the briefly and clearly discus about the Online Car
Modification System. Here we can clearly describe one by one step in picture view. So
before draw the site map hierarchical structure we discuss the outline of the html
structure that is used in our project.

● Index Page level 0
-Home.html level 1
Register.html
Login.html
Company.html
Privacy.html
Terms.html
Contact Us.html
Selectcar.html level 2
Selectjeep.html
Now we will illustrate it in a hierarchical structure.

4.3. Story boards
Story board is basically briefly describe the layout of your project. It can tell that what
the customers want and what type we need to use. This can also give the first look how to
build your navigational system. OCMS is the rough story board but you can easy
understand it when you use it.
The story board is user friendly and easy to use, it can tell the all procedure step by step
describe each and every thing. However, it can describe all the layout of your project.
And tell that what you want to show and what you explain.
When you click on page it can quickly response you and go to next other page. It can
show better graphics, better layout of the website.
So by the using of good tools and technology combination of HTML 5,CSS, Java Script,
jQuery and PHP it is very quick response and user friendly.
4.4. Navigational maps:

The next step is of navigational maps. The story board is used as a input but the
navigational maps is the clicking on different buttons and go to the one screen to the
another. In the other words when you click on button the action is depend on the button
but it can show the next other field.
4.5 Trace-ability Matrix

Following columns are involved in the trace-ability matrix.
Feature: Lists system features based on which use case are

built.
Use Case ID: Write the ID of the use case for easy lookup.
UI ID: Write the user interface ID for this use case.
Priority: Give an appropriate rating to each use case
according to its priority
Use Case Cross Ref: rite the related use cases separated with commas.
DB Table Id: write the relevant DB table ID’s
Elaborated Use-case ID: Elaboration of the related Use Cases separated by
commas.
Dependent Classes: List of Classes separated by commas which are
involved in achieving the Feature.
No Para System Specification Text Build Use Case Name Category

. #
1 1.0 Customer “shall” visit the website. B1 UC_Visit Business
2 1.0 Customer “shall” register himself B1 UC_Sign_Up Business

on website and take order to modify
his car.
3 1.0 Customer “shall” select category B1 UC_Select_Category Business
and select the car model.
4 1.0 Admin “shall” sign in and see the B1 UC_Login Business
order.
5 1.0 Admin “shall” perform operation B1 UC_Operation Business

CRUD.
6 2.0 Register user “shall” select and buy B1 UC_View_Parts Business

parts.
7 2.0 Register user “shall” select the B1 UC_View_Team Business

team.
8 2.0 Unregister customer “shall” only B1 UC_View_Parts Business

visit and see parts.
9 2.0 Database “shall” check the B1 UC_Check_Registration Business
registration of customer and start
work his car.
10 2.0 Customer “shall” login its ID and B1 UC_Register_View Business
check the parts and its price online.
11 3.0 Server “shall” check the validation. B1 UC_Validation Business

12 3.0 Garage provide good team and B1 UC_Team_Work Business
13 3.0 Changing “shall” be apply on cars B1 UC_Update Business
and modify it according to customer
requirement.
14 3.0 Invoice “shall” be generate and B1 UC_Invoice Business
ready for delivery.

Chapter 5: Software Testing

5.1 Introduction:
Software testing is an important activity to check whether the actual results match the
expected results and software is error free.
To accomplish this task, we will follow a variety of plans in performing maintenance and
non-functional testing of a website called Online Car Modification System.
Following are standard artifacts, which must be included in this deliverable:
1. Test Plan
2. Test Design Specification
3. Test Case Specification
1. Test Plan
2. Test Design Specification
3. Test Case Specification
4. Test Procedure Specification
5. Test Item Transmittal Report
6. Test Log
7. Test Incident Report
8. Test Summary Report
5.2. Test plan
7.2.1. Purpose
The system under testing that is Online Car Modification System project deals with the
main actors user, and admin. To plan a complete map following which we will be able to
carry out testing. Each functionality and module is given an appropriate time to check if
working properly or not. Group members will test the system so that errors and risk factor
shall be minimized.
5.2.2. Outline
A test plan shall have the following structure:
a. Test plan identifier

b. Introduction
c. Test items
d. Features to be tested
e. Features not to be tested
f. Approach
g. Item pass/fail criteria
h. Suspension criteria and resumption requirements
i. Test deliverables
j. Testing tasks
k. Environmental needs

l. Responsibilities
m. Staffing and training needs
n. Schedule
o. Risks and contingencies
p. Approvals
5.2.2.1. Test plan identifier

The plan for testing the system relates with the main actors like user and admin. A brief
plan consisting of different phases of testing will be produced by the team.
5.2.2.2. Introduction
The index page contains different events and buttons with graphical demonstrations and
interchanging color combinations. The login and registration system for user, and admin.
The procedure for selecting car and model and afterwards selecting parts. Group
members equally authorized to test the system following the plan to minimize ambiguity
resulting in better product.
A well-organized plan for quality assurance has been followed for a better final product.
Configuration and managerial techniques are followed to meet the standards.
5.2.2.3. Test items

The identification of test items and their version is discussed briefly and requirement of
hardware or software modules necessary for the revision of system under test.
No transfer of program from one media to another is necessary in order to test the
features. No special hardware required either. Testing of website will take place on a
simple computer. No special specs required.
5.2.2.4. Features to be tested

System features as discussed above like login and registration for user and admin. The
icons and events residing at the home page and each button should be tested like Home,
Shop Now, About, Privacy, Login.
Check the thumbnail of the website are working or not. User should select car, trucks.
Afterwards user will select the parts of his desire car and get the virtual idea how his
car will look like. Then after selecting parts, parts will be added to cart and user can buy
them.
 Making sure the cart is working properly and user is able to review the cart at the end
and will be able to add or remove items before invoice. If user want to install those parts
from garage then provide him a bunch of teams that are good in work and deliver their
work on time.
Admin will be able to add Sub-admins to the website. Both Admins and sub-admins
will be able to update data and add new data but only Admin will be able to delete the
data.

Updating team available for work is also important. At the end user will get invoice
and will be logged out as session expires.
5.2.2.5. Features not to be tested

At the home page pictures of cars are shown and at the end social links are given like
Facebook, Instagram and Google Plus. Checking each one of them is not necessary.
The name of website written anywhere in the website will redirect to home page of
website. Checking each link is not necessary because the relevant website scenario does
not demand it.
5.2.2.6. Approach
Performing testing on each major functionality involved the team members and each
member with his own technique and approach with computers of different categories,
specs and versions of hardware and software on them.
Different versions of browsers were used to check the working of website. Website has
been run on browsers offered by different software companies.
The load of data was increased and decreased through database to check the website if
large amount of data could flow through it or not. Sufficient time was given to test each
module and functionality. Major functionalities of selecting parts, adding parts to cart,
and selection of team etc. were given enough time frame for testing.
5.2.2.7. Item pass/fail criteria

Retrieval of data from database and time taken to respond particular query.
Links should take no more than 600 milliseconds to respond.
5.2.2.8. Suspension criteria and resumption requirements

o Participant fails to complete a task. So at some point that particular portion of
testing suspends.
o A participant fails a task but needs the information to continue. After getting info
the participant resumes.
5.2.2.9. Test deliverables

Identify the deliverable documents. The following documents should be included:
a. Test plan
b. Test design specifications
c. Test case specifications
d. Test procedure specifications
e. Test item transmittal reports
f. Test logs
g. Test incident reports
h. Test summary reports

5.2.2.10. Testing tasks
Team members that are going to involve in testing should be ready and motivated to
perform testing.
The qualification of team members should be checked beforehand.
Specify the time slots at which testing procedure must begin and make sure every team
member is available at that time.
You will need to schedule rooms, labs and equipment.
5.2.2.11. Environmental needs

Environment conditions for performing better testing is an important factor. A quiet and
calm place or environment is necessary for proper testing. The environment should be
equipped with fully supportive in the favor of test group, e.g. any hardware required
should be at an arms distance. Software must be readily available.
Specify spacious area for the members of test group. They should be provided with
environment where they can communicate easily as and when required.
Supply of electricity for computers or other hardware, proper arrangement of lights, air
conditioning and other equipment.
5.2.2.12. Responsibilities
Hire an outside agency: look for market research firms if there are none specializing in
usability recruiting, good screeners are vital. Your participants should adequately reflect
your true base of users and the user types you have decided to test, and represent a range
of new and experienced users in a way that would actually use your product.
In addition to a designated person to help you observe and log data, there may be a long
list of stakeholders who will benefit from observing a test.
They commonly include the developers, managers, product managers, quality testing
analysts, sales and marketing staff, technical support and documentation.
5.2.2.13 Staffing and training needs

When doing your own recruiting you should identify criteria that will help you select
qualified candidates. Experience with the product or the field, computer experience, age
and other demographics may be important to consider, e.g. Current product
users/customers who have used X(specific) Product for at least 1 year and use it at least 3
times a month.

5.2.2.14. Schedule
Schedule your participants to have adequate time to work through the test at their own
pace. Allow enough time between sessions to reset, debrief and regroup.
Time Slots Mon, Feb 25 Tue, Feb 26 Wed, Feb 27

11am – 12am Index Index /Home Admin portal, Editing
12:30am – 1:30pm Client portal, Editing Login, Admin Portal Search car
2pm – 3pm Select parts Add to cart Adding and removing

sub-admin
5.2.2.15. Risks and contingencies
 If testing of a particular module or function fails completely we have to

remove that particular module.
 A broken or empty link encountered during testing will disturb time frame in
future.
 Skipping the testing of any block due to any reason could be disastrous.
5.2.2.16 Approvals
Name/Title :
Date :
Signature :

5.3. Test design specification
5.3.1. Purpose
To prescribe the scope, approach, resources, and schedule of the testing activities. To
identify the items being tested, the features to be tested, the testing tasks to be performed,
the personnel responsible for each task, and the risks associated with this plan.
5.3.2. Outline
A test plan shall have the following structure:
a. Test plan identifier.

b. Introduction.
c. Test items.
d. Features to be tested.
e. Features not to be tested.
f. Approach.
g. Item pass/fail criteria.
h. Suspension criteria and resumption requirements.
i. Test deliverables.
j. Testing tasks.
k. Environmental needs.
l. Responsibilities.
m. Staffing and training needs.
n. Schedule.
o. Risks and contingencies.
p. Approvals.
The sections shall be ordered in the specified sequence. Additional sections may be
included immediately prior to Approvals. If some or all of the content of a section is in
another document, then a reference to that material may be listed in place of the
corresponding content. The referenced material must be attached to the test plan or
available to users of the plan.
Details on the content of each section are contained in the following sub-clauses.

5.3.2.1 Test plan identifier
The plan for testing the system relates with the main actors user, admin and sub-admin.
Participants of testing comprised of qualified and experienced team members.
A brief plan consisting of different phases of testing will be produced by the team.
5.3.2.2. Introduction
The index page contains different events and buttons with graphical demonstrations and
interchanging color combinations. The login and registration system for user and admin.
All the group members equally authorized to test the system following the plan to
minimize ambiguity resulting in better product.
5.3.2.3. Test items
simple computer. No special specs required. All the hardware and software necessary is
provided to be installed.
5.3.2.4. Features to be tested
 The icons and events at the home page and each button should be tested {Home,
Link, About, Contact, Login.}
 Check the thumbnail of cars at the home or index page.
 User shall select the car type then select the car and afterwards after selecting the
parts he should be adding them to cart.
 The procedure for selecting parts and all the criteria.
 The prices of the parts and their specification.
 Admin being able to crud the data and able to add a sub-admin.
 Sub-admin only able to create and update the data and not able to delete the data.
 Validation of Login process
 Only registered user shall be able to use add to cart feature.
 Team for installing the parts should be working.

5.3.2.5. Features not to be tested
 [Home page contain awesome buttons with a social media icon {Facebook,
Twitter, Google Plus and LinkedIn}.
 Title of website either leading to home or not.
5.3.2.6. Approach
Team members and each member with his own technique and approach with computers
of different categories, specs and versions of hardware and software on them.
been run on browsers offered by different software companies.
The load of data was increased and decreased through database to check the website if
large amount of data could flow through it or not.
Sufficient time was given to test each module and functionality.
Major functionalities of setting appointments, testing messages sent/received, notification
serving etc. were given enough time frame for testing.
5.3.2.7. Item pass/fail criteria
o Retrieval of data from database and time taken to respond particular

query.
o Links should take no more than 600 milliseconds to respond.
5.3.2.8. Suspension criteria and resumption requirements
o Participant fails to complete a task. So at some point that particular portion of

testing suspends.
o A participant fails a task but needs the information to continue. After getting info
the participant resumes.
5.3.2.9. Test deliverables

Identify the deliverable documents. The following documents should be included:
a. Test plan
b. Test design specifications
c. Test case specifications
d. Test procedure specifications
e. Test item transmittal reports
f. Test logs
g. Test incident reports
h. Test summary reports

5.3.2.10. Testing tasks
Team members that are going to involve in testing should be ready and motivated to
perform testing.
The qualification of team members should be checked beforehand.
Specify the time slots at which testing procedure must begin and make sure every team
member is available at that time.
You will need to schedule rooms, labs and equipment.

Some of the conditions required for performing better testing are discussed. A quiet and
calm place or environment is necessary. The environment should be equipped with fully
supportive in the favor of test group, e.g. any hardware required should be at an arms
distance. Software must be readily available.
Specify spacious area for the members of test group. They should be provided with
environment where they can communicate easily as and when required.
Supply of electricity for computers or other hardware, proper arrangement of lights, air
conditioning and other equipment.
5.3.2.12. Responsibilities
They commonly include the developers, managers, product managers, quality testing
analysts, sales and marketing staff, technical support and documentation.
 May be hiring an outside agency.
 Stakeholders.
5.3.2.13. Staffing and training needs

Current product users/customers who have used X(specific) Product for at least 1 year 4
males. Training include 60 minutes of workshop.
5.3.2.14. Schedule

sub-admin

5.3.2.15. Risks and contingencies

future.
 Skipping the testing of any block due to any reason could be disastrous.
5.3.2.16. Approvals
Name/Title :
Date :
Signature :
5.4. Test Case Specification
5.4.1. Purpose
The system under testing that is online car modification system deals with the main actors
user and admin. Each functionality and module is given an appropriate time to check if
working properly or not like selecting car, parts and adding them to cart. Group members
will test the system so that errors and risk factor shall be minimized.
5.4.2. Outline
A test case specification shall have the following structure:
a. Test case specification identifier

b. Test items
c. Input specifications
d. Output specifications
e. Environmental needs
f. Special procedural requirements
g. Inter case dependencies

5.4.2.1. Test case specification identifier
The plan for testing the system relates with the main actors like doctor, patient and
admin. A brief plan consisting of different phases of testing will be produced by the team.
5.4.2.2 Test items

simple computer. No special specs required. All the hardware and software necessary is
provided to be installed.
5.4.2.3. Input specifications

All of the icons and events at the home page and each button has to be clicked atleast
once. Each field provided in the site must be checked by providing a number of inputs.
The login and registration system for user and admin requires inputs like username and
password. For example
User:- Email : kashif@mail.com
Password : 12345
Mobile No : 03214567890
Email : admin@mail.com
Password : 12345
Try omitting ‘@’ from email. Try input by giving wrong passwords to check validations
on fields. Enter too long or too short string in the email field.
Validating numbers according to the format.
Validating Password according to the format whether it requires some special criteria or
not.
While selecting the car model the list of available parts should be shown along with their
specification and prices.
While adding an item to the cart it should be added in the cart and if it is added twice ,it
should be present twice in the cart with the total no of products.
Cart should have record and total price of the parts selected by user and after
confirmation should get invoice.
5.4.2.4. Output specifications

Specify all of the outputs and features (e.g., response time) required of the test items.
Provide the exact value (with tolerances where appropriate) for each required output or
feature.

5.4.2.5.1. Hardware
 A normal computer with minimum hardware specifications with dual core
processor i3, 1.5 GigaHz 2Gb RAM.
 An average AMD processor with 2Gb RAM.
 A desktop with core2duo processor.
 A good computer core i5 2.5 GigaHz 4Gb RAM.
5.4.2.5.2. Software
Windows operating system is best. Windows 7, 8, 8.1, window 10[ professional,
enterprise, enterprise N, Education or any.]
Application software like google chrome, Mozilla, Firefox, opera, safari etc. version not
too old but 5+, 7+ or 8+.
5.4.2.3. Inter case dependencies

Xampp server must execute properly and start Apache engine and Mysql database.
In the URL make sure password should not be visible and apply appropriate hash
functions to passwords for security.
5.5. Test procedure specification
5.5.1. Purpose
To specify the steps for executing a set of test cases or, more generally, the steps used to
analyze a software item in order to evaluate a set of features.
5.5.2 Outline
A test procedure specification shall have the following structure:
a. Test procedure specification identifier

b. Purpose
c. Special requirements
d. Procedure steps
5.5.2.1. Test procedure specification identifier

The plan for testing the system relates with the main actors like doctor, patient and
admin. A brief plan consisting of different phases of testing will be produced by the team.

5.5.2.2. Purpose
User, admin and sub-admin. Group members will test the system so that errors and risk
factor shall be minimized.
5.5.2.3. Special requirements

Set criteria that will help you select qualified candidates.
Experience with the product or the field, computer experience, age and other
demographics may be important to consider, e.g. Current product users/customers who
have used X(specific) Product for at least 1 year and use it at least 3 times a month.
5.5.2.4. Procedure steps

Include the steps in 8.5.2.4.1 through 8.5.2.4.10 as applicable.
5.5.2.4.1. Log
By default, the test log is automatically opened at the end of the test run session.
5.5.2.4.2. Set up
The Show log on pause option is enabled, TestComplete displays the temporary test log
when the test is paused. You can also open logs of previous test runs from the Project
Explorer panel, which lists all available logs for the currently opened project suite and its
projects.
5.5.2.4.3. Start
After running a test, you can view test results in TestComplete.
5.5.2.4.4. Proceed
You can filter test results to display only the information you are interested in or you can
view only error messages.
5.5.2.4.5. Stop
pw.close()
fos.close()

5.6. Test item transmittal report
5.6.1. Purpose
To identify the test items being transmitted for testing. It includes the person responsible
for each item, its physical location, and its status. Any variations from the current item
requirements and designs are noted in this report.
5.6.2. Outline
A test item transmittal report shall have the following structure:
a. Transmittal report identifier

b. Transmitted items
c. Location
d. Status
e. Approvals
5.6.2.1. Transmittal report identifier

Test Item ID: xyz
Project Name: Online Car Modification System.
5.6.2.2. Transmitted items

Files of front end, back end, Models, Views and Controllers.
5.6.2.3. Location
Hard drive of system.
5.6.2.4. Status
Transmitted completely.
5.6.2.5. Approvals
Name/Title :
Date :
Signature :

5.7. Test log
5.7.1. Purpose
To provide a chronological record of relevant details about the execution of tests.
5.7.2. Outline
A test log shall have the following structure:
a. Test log identifier;
b. Description;
c. Activity and event entries.
5.7.2.1. Test log identifier
By default, the test log is automatically opened at the end of the test run session.
5.7.2.2. Description
The Show log on pause option is enabled, Test Complete displays the temporary test log
when the test is paused. You can also open logs of previous test runs from the Project
Explorer panel, which lists all available logs for the currently opened project suite and its
projects. After running a test, you can view test results in Test Complete.
You can filter test results to display only the information you are interested in or you can
view only error messages.
A normal computer with minimum hardware specifications with dual core processor i3,
1.5 GHz 2Gb RAM.
An average AMD processor with 2Gb RAM.
A desktop with core2duo processor.
A good computer core i5 2.5 GHz 4Gb RAM.
5.7.2.3. Activity and event entries

sub-admin
5.7.2.3.1. Procedure Results

been run on browsers which are freeware offered by different software companies. The

load of data was increased and decreased through database to check the website if large
amount of data could flow through it or not.
5.8. Test incident report
5.8.1. Purpose
To document any event that occurs during the testing process that requires investigation.
5.8.2. Outline
A test incident report shall have the following structure:
a. Test incident report identifier

b. Summary
c. Incident description
d. Impact
5.8.2.1. Test incident report identifier

Test Item ID: xyz
5.8.2.2. Incident description

Incident Test Inputs Expected Results Anomalous Observations
Case Results
1 Login Email. Error if wrong input. Both Transfers responding
Password. Portal if correct successful
2 Select Select parts Price and Getting details Parts with the
Car specification of item picture of car
3 Add to Selecting Added to cart Added to cart Items in cart
cart parts successfully
5.9. Test summary report
5.9.1. Purpose
To summarize the results of the designated testing activities and to provide evaluations
based on these results.
5.9.2. Outline
A test summary report shall have the following structure:
a. Test summary report identifier
b. Summary
c. Variances

d. Comprehensive assessment
e. Summary of results
f. Evaluation
g. Summary of activities
h. Approvals
5.9.2.1. Test summary report identifier

Specify the unique identifier assigned to this test summary report.
5.9.2.2. Summary
Performing testing on each major functionality involved the team members and each
member with his own technique and approach with computers of different categories,
specs and versions of hardware and software on them.
Major functionalities of selecting car type, selecting parts and adding them to cart and
review of cart item at the time of invoice were given enough time frame for testing.
All group members will test the system so that errors and risk factor shall be minimized.
Inputs were specified to test a number of inputs to check login system. Validation was
working well.
Hardware and software being used to test the site were specified. Normal and average
level systems were used thus computer with high specs not required
5.9.2.3. Variances
No such variances reported
5.9.2.4. Comprehensiveness assessment

The plan for testing the system relates with the main actors like user (may registered and
un-registered), Admin and sub-admin. Participants of testing comprised of qualified and
experienced team members.
Social media icon for instance Facebook, Twitter, Google Plus and LinkedIn. The reason
is not every person have account.
5.9.2.5. Evaluation
features. No special hardware required either.
Item pass/fail:

o Retrieval of data from database and time taken to respond particular
query.
o Links should take no more than 600 milliseconds to respond.
Some of the risk factors that might arise while testing are as follows:
future.
5.9.2.6. Summary of activities

User, admin and sub-admin. Experience with the product or the field, computer
experience, age and other demographics may be important to consider, e.g. Current
product users/customers who have used X(specific) Product for at least 1 year and use it
at least 3 times a month.
Test team: 5 males.
Login procedure. Time elapsed: 0.83s
The procedure for setting appointment or sending for approval to doctor.
Time elapsed: 1.003s.
Admin being able to add data view data update data and delete the data but sub-admin
can only view data add data and update the data but cannot delete the data. Home page
header contain icons and events, clicks on them: 1 click, responding time 0.9s.
5.9.2.8. Approvals
Name/Title :
Date :
Signature :


(OCMS) Final Project Documentation Complete CC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(OCMS) Final Project Documentation Complete CC

Uploaded by

Copyright:

Available Formats

CS- UOG - Project Coordination Office Version: 1.

Department of Computer Science

University of Gujrat, Lahore Sub Campus

ONLINE CAR MODIFICATION SYSTEM

Session: BSCS Fall 2015-2019

Project Supervisor: Haroon Shahzad

Abram JOhn 15111519-063

Hamza Asghar 15111519-084

Shehroz Akhtar 15111519-047

Usama Bin Munir 15111519-155

Department of Computer Science,

© Computer Science, University of Gujrat, Lahore Sub Campus Page 1

© Computer Science, University of Gujrat, Lahore Sub Campus Page 2

Date: December 5, 2018

© Computer Science, University of Gujrat, Lahore Sub Campus Page 3

© Computer Science, University of Gujrat, Lahore Sub Campus Page 4

CHAPTER 1: PROJECT FEASIBILITY REPORT.....................................................1

1.8. INTRODUCTION TO TEAM MEMBER AND THEIR SKILL SET......................................10

© Computer Science, University of Gujrat, Lahore Sub Campus Page 5

3.6. OPERATION CONTRACTS.........................................................................................31

© Computer Science, University of Gujrat, Lahore Sub Campus Page 6

© Computer Science, University of Gujrat, Lahore Sub Campus Page 7

© Computer Science, University of Gujrat, Lahore Sub Campus Page 1

1.2. Project/Product Feasibility Report

1.2.1. Technical Feasibility

© Computer Science, University of Gujrat, Lahore Sub Campus Page 2

1.2.8. Legal & Ethical Feasibility

1.3. Project/Product Scope

© Computer Science, University of Gujrat, Lahore Sub Campus Page 3

2 Proposal. Mr. Haroon Self-development

3 Requirement Analysis. Proof reading, Self-development

7 Finalization. QA. Self-development

1.4.1. Project Cost Estimation by Function Point Analysis

Functional Low Values Average High Values FP Counts

© Computer Science, University of Gujrat, Lahore Sub Campus Page 4

Factor Value (0-5)

External Inputs 2*4=8

FP est. = Count Total * [0.65 + 0.01 * (Fi)]

The formulae are given as follows:

Cost / FP = labor rate / productivity parameter

Total Project Cost = FP est. * (cost / FP)

Total Estimated Effort = FP est. / productivity parameter

© Computer Science, University of Gujrat, Lahore Sub Campus Page 5

1.4.2. Project Cost Estimation by using COCOMO’81 (Constructive Cost Model)

Parameters of Different Modes:

© Computer Science, University of Gujrat, Lahore Sub Campus Page 6

Average Staff Size = Effort/Dev Time

1.5. Task Dependency Table

Sr. No. Activity Predecessor Duration(weeks)

1.6. CPM - Critical Path Method

© Computer Science, University of Gujrat, Lahore Sub Campus Page 7

The parameters and slacks are calculated as follows:

The critical path is:

1.7. Gantt chart

Task Name Start Week Week Duration

Online Car Modification System

Start Week Week Duration End Week

1.8. Introduction to Team member and their skill set

Members Name Skill Set Tasks

Usama Bin Munir Documentation, Designing Interface Testing, Structure

© Computer Science, University of Gujrat, Lahore Sub Campus Page 9

Task Duration Dependencies Members

Task durations and dependencies