Vehicle System Online

Online Vehicle Showroom
Developed
By
Muhammad Qasim
08-arid-1252
Muhammad Shafiq
08-arid-1254
Supervised
By
Madam Bushra
Hameed
Sheraz Akram
Dr. Zia ul Quyyum
MASTER OF COMPUTER SCIENCE

MCS
UNIVERSITY INSTITUTE OF INFORMATION TECHNOLOGY

PIR MEHR ALI SHAH ARID AGRICULTURE UNIVERSITY
RAWALPINDI JULY, 2011
ONLINE VEHICLE SHOWROOM
Dedicated to our beloved parents and to all

those, whose prayers always pave the way to
success for us.
UIIT, PMAS, UAAR, 2011 Page ii

PROJECT IN BRIEF
Project Title : Online Vehicle Showroom
Site :
Undertaken By : Muhammad Qasim

Muhammad Shafiq
Supervised By : Madam Bushra Hameed
Date Started : 15-03-2011
Date Completed : 20-07-2011
Technologies Used : Visual Studio 2008,

SQL Server Management Studio2005
Operating System : OS Window XP 2006
Web Server : IIS (Internet Information server)
Hardware Used : GSM Device (SONY ERICSSON W580i)

Dell Latitude D630
(CPU: 2.0MHz, RAM: 2 GB & Hard Disk: 160 GB)
ACKNOWLEDGEMENT
UIIT, PMAS, UAAR, 2011 Page iii

Thanks to Almighty Allah for giving us knowledge, power and strength
to accomplish this task. We learned a lot while doing this project and
this will certainly help us in our forth coming life. Many friends of us
helped us during this project but we are really thankful to Madam
Bushra Hameed from University Institute of Information Technology,
who helped us in all the phases of this project. Her supervision helped
us a lot during the times of difficulties. In the end we would like to
thank all of our Teachers and friends for their support and
encouragement.
MUHAMMAD QASIM
MUHAMMAD
SHAFIQ
UIIT, PMAS, UAAR, 2011 Page iv

DECLARATION
We hereby declare that this software, neither as a whole nor as a part
has been copied out from any source. It is further declared that we
have developed this software and accompanied report entirely on the
basis of our personal efforts. If any part of this project is proved to be
copied out from any source or found to be reproduction of some other.
We will stand by the consequences. No portion of the work presented
has been submitted in support of any application for any other degree
or qualification of this or any other university or institute of learning.
MUHAMMAD QASIM
MUHAMMAD
SHAFIQ
UIIT, PMAS, UAAR, 2011 Page v

CERTIFICATION
It is certified that the contents and form of the project entitled “Online
Vehicle Showroom” submitted by Muhammad Qasim (08-arid-1252)
and Muhammad Shafiq
(08-arid-1254) has been found satisfactory for the requirements of
University Institute of Information Technology
PMAS - Arid Agriculture University,
Rawalpindi
For the award of the degree of
MASTER OF COMPUTER SCIENCE

MCS
Supervisor: ________________________
Madam Bushra Hameed
Member 1: ________________________
Mr. Sheraz Akram
Member 2: ________________________
Mr. Ghulam Mustafa
Dated: ______________ Director: ________________________

Dr. Zia ul Quyyum
UIIT, PMAS, UAAR, 2011 Page vi

ABSTRACT
The “Online Vehicle Showroom System” a web application is

intended to provide complete solutions for vendors (Seller) as well as
customers (Buyers) through a single gateway i.e. using the internet
as the sole medium. It will enable vendors to put their vehicles online
for shopping, customer to browse through the System and purchase
the vehicles online without having to visit the showroom physically. If
users fails to find the vehicle of their choice they can put their
request, whenever vehicle of their choice is available they will be
informed by Email/ SMS. The system also provides the facility of
advertisements and discussion forum as well.
TABLE OF CONTENTS
Page #
University Institute of Information Technology....................................................vi
PMAS - Arid Agriculture University,......................................................................vi
UIIT, PMAS, UAAR, 2011 Page vii

Rawalpindi...........................................................................................................vi
PROJECT OVERVIEW..................................................................................1
TOOLS & TECHNOLOGIES USED..................................................................6
3.1 INTRODUCTION.................................................................................12
3.1.1 PURPOSE ....................................................................................................12
3.1.2 DOCUMENT CONVENTIONS.............................................................................12
3.1.3 INTENDED AUDIENCE AND READING SUGGESTIONS............................................13
3.1.4 PROJECT SCOPE............................................................................................13
3.1.5 REFERENCES................................................................................................14
3.2 OVERALL DESCRIPTION......................................................................14

3.2.1 PRODUCT PERSPECTIVE..................................................................................14
3.2.2 PRODUCT FEATURES.....................................................................................15
3.2.3 USER CLASSES AND CHARACTERISTICS............................................................16
3.2.4 OPERATING ENVIRONMENT............................................................................16
3.2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS...................................................16
3.2.6 USER DOCUMENTATION.................................................................................17
3.2.7 ASSUMPTIONS AND DEPENDENCIES..................................................................17
3.3 SYSTEM FEATURES............................................................................17

3.4 EXTERNAL INTERFACE REQUIREMENTS...............................................18
USER INTERFACES.................................................................................................18
HARDWARE INTERFACES.........................................................................................19
SOFTWARE INTERFACES..........................................................................................19
3.6 COMMUNICATIONS INTERFACES..........................................................................20
3.7 OTHER NONFUNCTIONAL REQUIREMENTS...........................................23

3.7.1 PERFORMANCE REQUIREMENTS.......................................................................23
3.7.2 SAFETY REQUIREMENTS.................................................................................23
3.7.3 SECURITY REQUIREMENTS..............................................................................23
Only the authorized person can access the database connected with the Server.
Access person can update or delete it................................................................24
3.7.4 SOFTWARE QUALITY ATTRIBUTE....................................................................24
Reliability.....................................................................................................................24
Flexibility.....................................................................................................................24
Performance & Ease of use..........................................................................................24
Maintainability.............................................................................................................24
UIIT, PMAS, UAAR, 2011 Page viii

Interoperability............................................................................................................24
Portability....................................................................................................................24
Database.....................................................................................................................24
TEST OBJECTIVES....................................................................................67
6.2 TESTING PROCESS.............................................................................68
7.1 ACHIEVEMENTS.....................................................................................124
7.2 LIMITATIONS...................................................................................................125
7.3 FUTURE WORK...............................................................................................125
UIIT, PMAS, UAAR, 2011 Page ix

Chapter 1
INTRODUCTION
PROJECT OVERVIEW
This online system facilitates the users to sale and purchases
their vehicles. Sellers who want to sale their vehicles they
have to register and then provide their vehicle’s information
from basic features to extra features along with vehicle’s
photos. Buyers can view vehicle’s information of their choice.
The system has following features
1.1.1 User Registration

Users have to register before buying, selling, placing ads,
placing bids and taking part in discussion forum through user
registration form.
1.1.2 Selling & Buying Vehicles

Sellers provide their vehicle’s information from basic features
to extra features along with vehicle’s photos. Buyers can view
vehicle’s information of their choice.
1.1.3 Sending Email/SMS

This module provides the facility to sellers/buyers to inform
by e-mail as well as SMS.
It means that whenever a buyer’s choice not found he/she

can put request and if his/her choice is uploaded then the
informed by email/SMS.
1.1.4 Vehicle Bidding
UIIT, PMAS, UAAR, 2011 Page 1

Any user can place bid to sale his/her vehicle. The system
will provide both options i.e. normal sale as well as bidding
sale.
1.1.5 User Friendly Search
i. This module provides the facility to visitors to search the
vehicles of their particular choice.
ii. No account management or registration is done for visitors.
iii. If any visitor selects any vehicle to purchase then it will

treated as a buyer and will be registered.
1.1.6 Discussion Forum
Sellers and buyers can discuss their issues about
vehicles such as price (actual market value), faults,
fraud cases, vehicle industry updates, motor shows and
related events etc.
1.1.7 Advertisements
Any user can place advertisement including general ads,
vehicle sale ad, vehicle buying ad and bid ad
1.2 PROJECT SCOPE

A web application is intended to provide complete
solutions for vendors (Seller) as well as customers
(Buyers) through a single gateway i.e. using the internet
as the sole medium. It will enable vendors to put their
vehicles online for shopping, customer to search through
the System and purchase the vehicles online without
having to visit the showroom physically. It will save time
consumed in manual purchasing. It will also facilitate the
client without profit and loss.
1.3 PROJECT OBJECTIVES

Following are the main objectives of our system:

i. Advance Search & User Friendly Engine.
ii. Increase website audience.
iii. Buyer and seller can add and edit listings without any HTML knowledge
and less work (not lengthy procedure).
iv. Photos are automatically resized and optimized.
v. Help includes a step by step Wizard and detailed User Manual.
vi. User account manager
vii. Multiple account types
viii. Customizable account privileges
ix. Support for an unlimited number of vehicles registration in an account.
x. Customizable listing feature fields
xi. Modular code construction for easy site integration
1.4 PROPOSED SOLUTION

In this project
• We are intended to develop a solution to sale & purchase
vehicles
• We are going to propose a solution for those who don’t want
to go to vehicle dealers; they will be informed by E-mails/SMS.
• We are also providing a communication in the form of sending
SMS from computer to mobiles.

User (Admin, Seller, Buyer, Mechanic)

User PC
Web Browser
Windows OS
HTTP
IIS
Web Server
POP3, SMTP and HTTP

Wi n d o w s
Ser v er
Server (Mainframe)
E ma i l
Se r v er
GSM
Fig 1.1 System architecture SMS Gateway
mo bi l e
1.5 PROPOSED SYSTEM COMPONENTS
Our proposed solution has following components

Buyer Seller
Cell Phone Cell Phone
1.5.1 GSM device:

GSM (Global System for Mobile Communications) is second
component of our proposed System and it is responsible for sending
and receiving SMS to and from the users. Server will extract SMS
from GSM device and send SMS to the GSM device.
1.5.2 Web server:

IIS (Internet Information server is used as a Web server)
1.5.3 Microsoft SQL Server

To maintain information of the system SQL Database Server 2005
will be used.
1.5.4 Email Server

Email server will be used to send emails to sellers as well as buyers

1.5.5 Database:
Database component is use to store the information of users and
also to maintain the log of sending and receiving Emails.
TOOLS & TECHNOLOGIES USED

OS Window XP
Visual Studio.net 2008
Microsoft SQL Server 2005
Mcore (SMS Sending and Receiving)
Sony Ericsson/Nokia PC Suite
Internet Explorer 7, Mozilla Firefox3.5
Hardware: GSM Device (SONY ERICSSON W580i)

Dell Latitude D630
(CPU: 2.0MHz, RAM: 2 GB & Hard Disk: 160 GB)

Chapter 2
LITERATURE REVIEW
2.1 Literature review

Consumers prefer to go to the Internet to shop for a vehicle to
get information to make a buying decision without having to visit a
dealership. Sometimes they turn to the World Wide Web vs. their
local car row to avoid being pressured by a self serving car
salesperson -- real or imagined. Other times their objective may be
to save gas and time before they jump into the real world where
they may be pressured into making a premature buying decision
based on emotion and limited information. Frankly, in many cases,
they are right; can you say -- spot delivery.
Job one for search engines, like Google, is to provide relevant
information to their online customers to help them narrow down
their list of vehicles of interest and answer associated questions like
trade-in value, payment options and the many items that must be
addressed before they can select -- the -- vehicle vs. -- a -- vehicle.
Once those issues are resolved, they need to help their online
shoppers find an auto dealer that can provide a vehicle that best
satisfies those terms and conditions; in that order -- vehicle first and
dealer second. My point is that when Google first directs their
customers to the most relevant source for their desired information
it is not necessarily limited to a particular dealership. Today's car
shoppers are much better educated than yesterday's. They know
what questions they need to ask before they can make a buying
decision so their online search words are more able to target
vehicles that warrant their consideration rather than limiting their
search to their local car dealerships. For better or worse, auto
dealers can't put that horse back in the barn!

The adversarial relationship between consumers and auto

dealers that governed old world selling processes originated in the
real world to help auto dealers control the shopping and negotiation
process and they survived briefly on the virtual showrooms being
built one on the Internet, but -- today and tomorrow -- not so much!
Once auto dealer's realized -- or more correctly -- once customers
told auto dealers that they no longer controlled the access to the
information that they needed to purchase a vehicle the dealers tried
to control the information on the Internet; how is that working out
for auto dealers!
Automotive advertising agencies first assumed that S.E.O. and
S.E.M. was a way to put Google on the auto dealer's side of the
Internet Super Highway. If they placed the right search words, meta
tags, URL names -- and the various manipulations of the Google
search algorithms that automotive advertising agencies have
memorized as fast as Google changes them -- then they could
manipulate the search results to place their auto dealer clients as
the most relevant source for the information that customers were
searching for and earn the auto dealers a position on the car
shoppers short list. Given the vertical priority placed by Google to
position a listing on page one based on relevancy to their customers
search words or phrases, that technique certainly has value.
However, since customers are prioritizing finding a vehicle before a
dealer and/or to answer related questions before they open
negotiations on a specific vehicle at a particular auto dealer, auto
dealers that base their online marketing efforts to accomplish that
priority are positioning themselves mid-sales cycle and they may be
a day late and a dollar short for a large portion of today's and
tomorrow's shoppers/buyers.
Automotive advertising agencies have attempted to answer
customer's questions on their auto dealership' websites in an
attempt to earn them a top position on vehicle based searches.
Their assumption is that the more information the better -- as long

as it is relevant -- however, once at the auto dealer's site the more

accurate priority is "transparency!" More time on page, and more
page visits used to be considered a good thing but today, once
again -- not so much! The easier and faster the online car shopper
can find the specific information that they need to make a buying
decision the better! Site designs are being simplified with more
intuitive user interface and dedicated landing pages or linked micro
sites to allow customers to limit the amount of "clicks" or wasted
exposure to information that may be relevant to the dealer but not
necessarily to the customer; at that time in their shopping cycle at
least.
Once the shopper actually ventures onto an online showroom
the plan is to keep them there by providing direct or linked access
to anything that they need to move themselves further down the
sales/buying funnel. The dealer may see these information
resources as a conversion tool or a lead generator but if they lose
track of the truth -- that the customer is still in charge -- they risk
losing them with the click of a mouse. Sorry, but throwing their
trade-in keys onto the roof won't work in your virtual showrooms!
The solution is for auto dealers to listen and learn from their
online customers before they presume to sell them anything!
Human nature has survived on the World Wide Web and relationship
based selling still has a strong influence on consumers. Today's
online shoppers are being directed by Google and the other search
engines to social networking sites because the marketplace is a
conversation and people are social animals. Auto dealers who want
to attract customers with a message that they are the best source
for information to serve the customer's interest vs. their own are
better served to have their customers make that case for them.
Next generation inventory based search portals -- like
ronsmap.com -- accept an auto dealer's inventory for free with the
ability to push their vehicles into social media using their vBack

application to Ask-A-Friend or Tell-A-Friend about the vehicle -- and

the dealer --that they are considering within their social networking
communities of online friends. Google has already admitted that
they are prioritizing real time social media to establish relevancy,
and automotive advertising agencies already know that more
vehicles on a site provide more relevancy to more online car
shoppers. As a result, they have found that the way to attract more
online customers to find their auto dealership as the place to go to
get all of their questions answered will be the message that is
carried along with their individual vehicles listed on this communal
consumer-centric site; which is what the customers are looking for
to begin developing their shortlist of dealers to do business with!
Customer friendly applications that distribute the information
on an auto dealer's individual website which have the secondary
value of functioning as a conversion tool or lead generator are also
key differentiators that quickly build branding value for an auto
dealer's virtual showroom and enhance their online reputation as
the place to go to get customer's questions answered vs. their being
sold something. For example, GetAutoAppraise.Com is a next
generation appraisal tool that provides credible third party trade-in
values sourced through NADA with integrated inventory information
that allows the customer to review the entire transaction more
efficiently. Their trade-in appraisal form includes vehicle, price and
payment information to and from both parties to the transaction in
one easy transparent and customer friendly process.
Video platforms, like SiSTeR Technologies Video CarLot, is
another transparent Google friendly application that converts
pictures on an auto dealer's website into interactive videos with
human voice that are also pushed out onto the World Wide Web
through their dedicated API to You Tube and soon to be announced
applications that push their vShock platform onto social networking
communities like Face Book. Their proprietary video platform is fully
index able for the search engines and it provides relevant

information to the customer from within the video as well as direct

links through their vShock application that opens a dedicated micro
site with similar vehicles chosen from the dealer's inventory using
algorithms and business rules custom designed by the dealer to
improve the customers vehicle selection. This process is another
example of a customer friendly information delivery system that will
improve transparency for the customer once they find an online
dealership which will also extend the auto dealers S.E.O..
The point is, the more information that an automotive
advertising agency provides through their auto dealer client's
websites in the most relevant and transparent manner the better.
However, auto dealers need to get online car shoppers to find and
visit their virtual showrooms first, and since information is a key
differentiator between them and their online competition -- or
according to Google and online shoppers, it should be - then the
information alone won't make it! Automotive advertising agencies
must focus on consumers' interests in order to best serve their auto
dealer clients because Google does; and Google does it because
their customers demand it!
C# (pronounced "see sharp") is a multi-paradigm programming

language encompassing imperative, functional, generic, object-
oriented (class-based), and component-oriented programming
disciplines. It was developed by Microsoft within the .NET initiative
and later approved as a standard by Ecma (ECMA-334) and ISO
(ISO/IEC 23270). C# is one of the programming languages designed
for the Common Language Infrastructure.
C# is intended to be a simple, modern, general-purpose, object-
oriented programming language. Its development team is led by
Anders Hejlsberg. The most recent version is C# 4.0, which was
released on April 12, 2010.for c# help we study the following books

Chapter 3
REQUIREMENT ANALYSIS
3.1 Introduction
3.1.1 Purpose
The “Online Vehicle Showroom System” a web application

that is intended to provide complete solutions for vendors
(Seller) as well as customers (Buyers) through a single gateway
i.e. using the internet as the sole medium. It will enable vendors
to put their vehicles online for shopping, customer to browse
through the System and purchase the vehicles online without
having to visit the showroom physically. If users fails to find
the vehicle of their choice they can put their request, whenever
vehicle of their choice is available they will be informed by
Email/ SMS.
This document is meant to delineate the features of OVS, so as

to serve as a guide to the developers on one hand and a
software validation document for the prospective client on the
other.
3.1.2 Document Conventions
Throughout this document, the following conventions have been

used: -
Font: Sylfaen
Size: 18 for Main Headings (Bold)
Size: 14 for Sub Headings (Bold)
Size: 12 for the rest of the document.

3.1.3 Intended Audience and Reading

Suggestions
This document is intended to serve the needs of the mobile users

mainly. This document will help developers, testers and project
manager to develop the project according to the user requirements
specified in this document.
User Type Description

Project It will help the Project Manager to manage the
Manager overall activities of project.
It will help the developers to develop the system
Developers
according to the specifications or requirements.
Testers will test the system according to the
Testers specifications and requirements mentioned in this
document.
Marketing It will help Marketing manager to advertise the
Managers product.
Document It will help document writer to write detailed
Writer document.
Table 2.1 Intended audiences
It could be of great use to the all type of mobile users. It aims at

describing the approach to the development of the Text to speech
tool and the procedures to implement it in mobile phones. So far,
there has been no significant advancement on this idea which is
relatively new but could be a great commercial success.
3.1.4 Project Scope
A web application is intended to provide complete solutions for

vendors (Seller) as well as customers (Buyers) through a single
gateway i.e. using the internet as the sole medium. It will
enable vendors to put their vehicles online for shopping,

customer to search through the System and purchase the

vehicles online without having to visit the showroom
physically. It will save time consumed in manual purchasing. It
will also facilitate the client without profit and loss.
3.1.5 References
• http://www.digitalfuturesoft.com/texttospeechproductsforpock
etpc.php
• http://www.w3.org/2004/09/ssml-pressrelease.html
• http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/
• http://www.ispeech.org/ap
• http://www.smartmuseum.eu/del/D3.1b_SM.pdf
• http://www.carcitysupercenter.com/
• http://www.usedcarshowroom.co.uk/
• http://www.usedcarshowroom.co.uk/
• Karl E. Wiegers SRS FORMAT (IEEE)
3.2 Overall Description

3.2.1 Product Perspective
This system is a follow-on member of existing online showrooms’

product family providing the facilities for bidding their vehicles. The
pictorial overall system as follows
Buyer Seller
Cell Phone Cell Phone
Fig 3.1 Product Perspective
3.2.2 Product Features
The proposed systems make use text of SMS and E-mail and
facilitate the user to listen it instead of reading it by them.
• Buyer’s Registration if he/she wants to buy vehicle

• Seller’s Registration if he/she wants to sale vehicle
• User Friendly Search
• Sending Emil/SMS
• Advertisements
• Bidding Vehicles

• Discussion Forum
3.2.3 User Classes and Characteristics
i. Buyers can search vehicles of their choice and put their

requests to be informed later email/SMS when choice will be
available.
ii. Sellers can upload their vehicle’s information including
pictures, model, manufacturer etc.
iii. Sellers can sale their vehicles on bid if they wish.
iv. Casual visitors can visit the site to check for their choice.
3.2.4 Operating Environment
3.2.4.1 Hardware Specifications
Server with Pentium IV, 1GB of RAM

GSM device
Mobile Phone
3.2.4.2 Software Specifications

Server with Windows Server 2006
IIS (Internet Information Server)
3.2.5 Design and Implementation Constraints
This section will indicate the design constraints that apply on the
system being developed and that shall be adhered to during the
development phase of the project.
Programming languages: The server programming that resides
on the Server shall be written in C# (Dot Net) using the Framework
(3.5) development kit.
Database: Microsoft SQL Server 2005 shall be used as the system’s
database management system. The database shall be stored on the
server. Development tools: The Microsoft Visual Studio 2008 and the
NetBeans2 6.7 IDE shall be used as the primary development tools
to build the server and client programs.

Standards: The server program shall be able to work under

Windows Server 2006, Windows XP etc. operating systems. The
server requires that the 3.5 Framework to be installed on the
Server. The Server hardware specifications must meet the minimum
requirements of 2.0 GHz CPU speed, 1 GB of RAM, and at least 20
MB of hard disk space for database storage. The client program
shall be able to function on all mobile phones that have the Java
Runtime Environment installed. GSM device should be used to send
and receive the SMS and E-mails.
Communication Protocols: The system should use the SMTP

(Simple Mail Transfer Protocol) and POP (Post Office Protocol) etc.
protocols to send and receive the E-mails and SMS.
Sustainability: The system is expected to live whenever needed.
3.2.6 User Documentation
User Manual will be provided with this tool. In those manuals the
complete guidance regarding to use this application will be provided
to the users.
3.2.7 Assumptions and Dependencies
It is assumed that the user possess a Java enabled mobile phone.

It is assumed that the text is in formal English only. It is important
for the text to speech conversion as well as the working of the
system.
3.3 System Features

The following modules/ features are in the system’s
scope
• Buyer’s Registration

• Seller’s Registration
• User’s Friendly Search for casual visitors can visit
the site to check for their choice.
• Sending Emil/SMS
• Advertisements
• Discussion Forum
• Vehicle Bidding
• Request For Vehicle
3.4 External Interface Requirements

User Interfaces
The User interface shall consist of various modules designed to help

you manage the system. Each module shall be representing a set of
questions. This would enable to work more efficiently. Record types
shall be related to one another.
The user interface for the system will be run on Server. A prototype
has been created that represents the final interface for the system
in terms of look and feel. The user interface will be limited to the
types of controls that can be generated using .NET controls. The
user interface code will be generated by individual developers, as
well as by the Microsoft Visual Studio Integrated Development
Environment.

Hardware Interfaces
The Hardware Interfaces of the system are handled by the Windows

Server 2006 Operating System, which is connected to the Internet.
GSM4 Device is another hardware component to communicate
between sending and receiving SMS. E-mails are sent to the user as
an SMS through the GSM device using SMTP protocol. User can reply
the E-mail as an SMS through the GSM device. The data will be use
by the GSM device for sending and receiving SMS. This device
communicates with the Server and Server is attached to the central
database.
Software Interfaces
• Operating System
The software is being designed to run on Windows Server 2006.
Windows Server 2006 includes the latest version of Internet
Information Services, version 8.0.
• Server
The software runs on the Server and can extract all the
E-mails from the Internet Server.
• Database
The software will access the Microsoft SQL Server 2005 Enterprise
Edition database for the following features.
Database can hold the following data.
 ID of each User.
 Phone Numbers of the Users.

 E-mail address of the Users.

 Maintain Log for each SMS and E-mail and also
maintain Chatting Log.
• Libraries
The software will be created using the Microsoft .NET version 3.5
Framework and also use Mcore or Ozeki 2009 for SMS interaction.
• Interface Layout Tools

Based on requirements, the group has selected Microsoft Visio 2007
for designing the UML diagrams. The necessary Interface layout
functionality is design using Adobe Photoshop 7.
3.6 Communications Interfaces
Following are the communication functions required for

communication with the Server and sending and receiving SMS
through GSM device.
• SMTP (Simple Mail Transfer Protocol) and Pop (Post Office Box)
etc. protocols are required to send and receive the SMS and E-
mails.
• GSM (Global System for Mobile Communications) device is
required to send and receive the SMS through Server.
• Server is required to send and receive E-mails from the
Internet.
• Windows Server 2006 should be installed on Server to get fast
and accurate data transfer.
• The security issues in Internet E-mail include secrecy, content
integrity, and identity integrity.

3.7 Functional Requirements

Above described features will have the following requirements?
o Buyer’s Registration
i. Buyer need to register before use the facilities to buy any
vehicle.
ii. All the information will be kept in database that includes
buyer’s particulars and required vehicle as well as its buying
(price) range.
iii. It also contains the record of bought vehicle by a particular
person.
o Seller’s Registration
i. Seller need to register before use the facilities to sale any
vehicle.
ii. All the information will be keep in database that includes
seller’s particulars (Name, Contact No. etc) and required vehicle
as well as its buying (price) range.
iii. It also contains the record of sold vehicles by a particular
person.
o User Friendly Search

i. This module provides the facility to visitors to search the

vehicles of their particular choice.
ii. No account management or registration is done for visitors.
iii. If any visitor selects any vehicle to purchase then it will
treated as a buyer and will be registered.
o Sending Emil/SMS
i. This module provides the facility to sellers/buyers to inform

by e-mail as well as SMS if case of seller/buyer response.
ii. It means that whenever a buyer’s choice not found he/she
can put request and if his/her choice is uploaded then the
informed by email/SMS.
o Advertisements
This module provides the all facilities
concerning to advertisements based on
priorities defined by payment/cost.
o Vehicle Bidding
Any seller can add bid to sale his/her vehicle.
The system will provide both options i.e.
normal sale as well as bidding sale.
o Discussion Forum
Sellers and buyers can discuss their issues

about vehicles such as price (actual market
value), faults, fraud cases etc.

3.7 Other Nonfunctional Requirements

3.7.1 Performance Requirements
• Response time for a sending and Receiving the SMS and E-

mails - average: maximum: 30 seconds. A response time
sending one E-mail or receiving one SMS.
• Throughput – an average of 2 transactions per minute.
• Capacity– the system can communicate with 100 mobile

users at the same time.
• Degradation mode - If the system is degraded when we

exceed 100 mobile users, we will remain in the normal
mode of operation with longer response time.
3.7.2 Safety Requirements
The following is a list of the safety requirements to indicate how the

system shall prevent any possible threat to system.
The system can send the E-mails to the required persons. The
system should have ability to check for required person from the
database.
3.7.3 Security Requirements
The following is a list of security requirements that indicate how the

system shall protect itself and its sensitive data and
communications from accidental, malicious, or unauthorized access,
use, modification, or destruction.
• The system shall not permit unauthorized persons to
access or participate in any activity started by the
server and client.
• The system shall not allow confidential data stored in
the system’s database to be accessed, whether directly
or indirectly, by client (mobile) users.

Only the authorized person can access the database

connected with the Server. Access person can update
or delete it.
3.7.4 Software Quality Attribute
Reliability
No interruption should be occurring wile sharing

information with each other.
Flexibility
Any module should be enhanced and added.
Performance & Ease of use
The Software will user friendly and enhance performance while

conducting Risk Assessment.
Maintainability
Any module can be maintainable individually. The application will be

easy to maintain and upgrade due to the use. The application will be
developed in modular structure so it will be easy to manipulate the
development process, testing, and maintainability.
Interoperability
The system will have interoperability with the other modules and to
Interact and function with other products or systems, without any
access or implementation restrictions.
Portability
The system can run on all kinds of mobile phones.

Other Requirements
Database
System can have small database which can store the E-mail address
as well as the phone numbers of corresponding E-mails. The

database can also maintain the history of E-mail to SMS and SMS to
E-mails conversions.
3.8 Appendix A: Glossary

This solely describes those terms which have been used with special
meanings, with reference to context.
1. .NET
This application can be develop in .NET Framework 3.5 with
C# and runs on Server.
2. GSM
GSM (Global System for Mobile Communications: originally from
Group Special Mobile) is the most popular standard for mobile
telephony systems in the world. This device is used to send and
receive SMS.

Chapter 4
SOFTWARE DESIGN
4.1 Use Case Diagram

4.2 Fully Dressed Use Cases
4.3 Domain Model
4.4 Class Diagrams
4.5 Activity Diagram
4.6 Sequence Diagrams
4.7 Operational Contracts
4.8 Deployment Diagrams
4.9 Entity Relationship Diagram

4.1 USE CASE DIAGRAM
Remove
Search Vehicle Post Add
Add
<<extends>> <<extends>>
<<include>>
Manage Bid Manage Ads

Search
Criteria
Send Bid info Finalize Bids
<<extends>>
Delete
Send Messages
Send SMS
E-mail
<<in
clud Manage Forum
e> >
System
Generated View vehicle
(automatic)
View Bid
History History Admin
Visitor
<<extends>>
View Overall
Register History
Forum
<< Feedback
in
cl u
Comments de
>>
Vehicle
Condition
Mechanic Authentication
e>>
clud
<<in
Search
Vehicle Place Bid
Mechanic
<<includes>>
Verify card Pay Bid Fee
Refundable
if bid fails
Place
Advertisement
e>>
clud
<< in
Put Request
Make Payment
Buyer
Seller Buy Vehicle
if desired
<<
>
vehicle not
e>
Sale Vehicle found

inc
ud
lud
cl
in
if any buyer
e>>
<
is waiting
<
Inform Inform View Vehicle

Upload
Buyer Buyer info
Vehicle Info
<<extends>> << e
x tend
<<extends>> s>>
Send Rate
Send SMS Mechanic
E-mail
System
Generated
(automatic)
4.1.1 Use case Model

4.2 FULLY DRESSED USE CASES
Use Case section Comment

Use Case name Vehicle Searching
Scope Online Vehicle Showroom System
Level User goal

Primary actor
Visitor
(Unregistered )
Stake holder and their Casual users: Want to search the vehicle of
interest their choice
Precondition Internet connection
The user will be able to search the required
Success guarantee
information
The system will provide fast and efficient
Main success scenario
searching
1. User can be registered to sale,

purchase, place advertisement etc
Extension
2. User can place bid
3. User can view bid history
User should have basic knowledge of using

Special requirement
internet (browsing)
Technology and data

Internet connection , HTML,ASP
variation list
Frequency of
Whenever any user want to visit the site
occurrence

Table: 4.2.1 Searching the Site (All Users/Visitors)
Use Case section Comments
Use Case name Visitor Registration
Level Sub Function
Primary actor Visitor

Stake holder and their Casual users: Want to register to become a
interest regular user
Precondition The user will make a Request for registration
The user will registered to access full
Success guarantee
functionality
The user will registered to access
functionality
1. After registration user will be informed

by SMS/ Email about user name &
Extension password
2. User will be informed by SMS/ Email
about vehicle sale, purchase, bidding etc
User should have basic knowledge of using

Special requirement
internet (browsing)
Technology and data

variation list
Frequency of
Whenever user request for registration
occurrence

Table: 4.2.2 User Registration (All Users/Visitors)
Use Case section Comments
Use Case name Visitor Registration
Level Sub Function

Stake holder and their
Casual users: Want to register to become a regular user
interest
Precondition The user will make a Request for registration
Success guarantee The user will registered to access full functionality
Main success scenario The user will registered to access functionality
1. After registration user will be informed by SMS/

Email about user name & password
Extension
2. User will be informed by SMS/ Email about
vehicle sale, purchase, bidding etc
User should have basic knowledge of using internet

Special requirement
(browsing)
Technology and data

variation list
Frequency of occurrence Whenever user request for registration

Table: 4.2.3 User Registration (All Users/Visitors)
Use case section Comments
Use Case name View overall history
Level Sub Function
All users: Registered as well as unregistered

Stake holder and their interest
Interest : To view overall history including
User may want to place a bid, advertisement, buy or sale
Precondition
vehicle
Success guarantee The user will registered to access full functionality
Main success scenario 1. The user will registered to place bid
1. After registration user will be informed by SMS/

Email about user name & password
Extension
2. User will be informed by SMS/ Email about
vehicle sale, purchase, bidding etc
Special requirement Registration is required to place bid
Technology and data variation list Internet connection , HTML,ASP
Whenever any user want to view the history or when the

Frequency of occurrence
user want to place the bid

Table: 4.2.4 View Bid History (All Users/Visitors)
Use case section Comment
Use Case name Manage Advertisements
Level Sub Function
Primary actor Administrator

Administrator: To manage Advertisements
Stake holder and their interest Interest : To place new advertisements and to remove
old advertisement
Administrator’s Authentication or advertisement
Precondition
placement
Administrator will manage Ads after registration &
Success guarantee
authentication
Managing Advertisements efficiently i.e.
Main success scenario • Posting advertisements
• Removing advertisements
1. To place new advertisements

Extension
2. To remove old advertisement
Special requirement Administrator’s Registration & authentication

Technology and data variation list
Ads may in image as well as video animation format
Whenever a new advertisement is to be placed
Frequency of occurrence OR
Whenever an old advertisement is to removed
Table: 4.2.5 Manage Advertisements (Administrator)


Use Case name Manage Bids
Level Sub Function
Stake holder and their Administrator: The authorized person

interest Interest : To manage bids
Precondition Administrator’s Authentication

Administrator will manage bids after registration &
Success guarantee
authentication
Managing bids i.e.
• Finalizing bids and informing users
• Bid announcement
• Removing bids
1. Finalize bids
Extension
2. Send bid information (SMS / Email)
Special requirement Administrator’s Registration & authentication
Technology and data

variation list
Whenever a new bid is to be placed

Frequency of occurrence OR
Whenever an old bid is to removed
Table: 4.2.6 Manage Bids (Administrator)


Use Case name Manage Forum
Level Sub function
Administrator: To manage forum

Interest : Remove unwanted messages & comments
Precondition Administrator’s Authentication

Administrator will manage forum after registration &
Success guarantee
authentication
• When users have to place comments and

Main success scenario messages log in is required
• It requires registration
1. Check the comments on the forum and remove

Extension unwanted messages.
2. To provide feedback about fake users and bids
Special requirement Administrator’s Authentication
Technology and data variation

list
Frequency of occurrence Once in a day to check and remove unwanted messages
Table: 4.2.7 Manage Forum (Administrator)

Use Case Section Comment
Use Case name Inspect vehicle’s condition
Level Sub function
Primary actor Mechanic
Mechanic: The registered & authorized person

Stake holder and their interest Interest : To check the vehicle’s condition and to
comment
Authorized person
Precondition
If sellers want to put comments about their vehicle
Success guarantee To check the vehicle’s condition and to put comments
• Inspect the vehicle if the seller wants to put

Main success scenario comments about condition.
• Log in and place the comments
1. Check vehicle’s condition

Extension
2. Comment about the vehicle and
Special requirement The registered & authorized person
Technology and data variation list Internet connection ,HTTP, HTML, ASP
When sellers want comments or mechanic want to

Frequency of occurrence
inspect vehicle
Table: 4.2.8 Vehicle Inspections (Authorized Mechanic)

Use case name Sale Vehicle

Level User goal
Primary actor Seller
Stake holder and their Sellers: The registered users
interest Interest : Want to sale the vehicle
Precondition User have to log in to sale vehicle
Success guarantee The sellers can sale their vehicles
1. Online user select sale vehicle option

2. They have to upload complete vehicle info
3. Mechanic’s comments increases reliability and chances of
selling vehicle
1. When online user select sale vehicle option

2. The system will prompt user to enter all correct
Vehicle info
3. Sellers can search a mechanic (authorized person) in their
Extension surroundings.
4. Mechanic’s comments increases reliability and chances
of selling vehicle
5. The system will generate the message automatically and
send to buyer if any buyer is waiting
Special requirement Seller registration is required

Technology and data
Internet connection , HTTP, HTML, ASP and GSM
variation list
Frequency of occurrence Whenever any seller want to sale vehicle
Table: 4.2.9 Sale Vehicle (For Registered Users)

Use case name Buy Vehicle
Level User goal
Primary actor Buyers
Buyers: The registered users

Interest : Want to buy the vehicle
Precondition User have to log in to buy vehicle
Success guarantee The buyers can buy vehicles

1. When online user select buy vehicle option
2. The system will show the vehicle info
Main success scenario 3. Sellers will give rating to mechanic of their choice
send to seller
1. When online user select buy vehicle option
2. The system will prompt show Vehicle info
3. Mechanic’s comments increases reliability and chances
Extension
of selling vehicle
send to buyer if any buyer is waiting
Technology and data variation list Internet connection , HTTP, HTML, ASP and GSM
Frequency of occurrence When buyer want to buy vehicle
Table: 4.2.10 Buy Vehicle (Registered Users)

Use case name Forum Feedback
Level Sub Function
Primary actor All registered users
Registered users : all registered users

Interest :to put comments and feedback
Precondition All registered users required authentication
Success guarantee All registered users can put comments and feedback
1. User will log in

2. User will put comments and feedback
1. User may help each other to identify fake users.

2. User may inform each other about vehicle industry
Extension
updates.
3. User may help each other in resolving vehicle faults.
Technology and data variation list Internet connection , HTTP, HTML, ASP
Frequency of occurrence Whenever user give feedback on forum
Table: 4.2.11 Forum Feedback (For Registered Users)

Use case name Put Buy Request
Level User goal
Primary actor Buyer
Buyer : all registered users

Interest :to put buy vehicle request
Success guarantee All registered users can put buy vehicle requests
1. User will log in
2. User will search to buy vehicle
Main success scenario 3. User will put buy vehicle request if vehicle is available
4. User will be informed by automatic system generated
SMS / Email when the required vehicle will be available
Frequency of occurrence Whenever user give feedback on forum
Table: 4.2.12 Put Buy Request (For Registered Users)

Use case name Place Advertisements
Level Sub Function

Interest : To place advertisements
Success guarantee All registered users can place advertisements
1. User will log in

Main success scenario 2. User will place advertisements
3. User will make payment
1. User will place advertisements to sale vehicle

Extension
2. User can place any advertisements
Frequency of occurrence Whenever user want to place advertisements
Table: 4.2.13 Place Advertisements (For Registered Users)

Use case name Place Bids

Level Sub Function

Interest :to place bids
All registered users required authentication and bid registration fee

Precondition
that is refundable if the bid fails
Success guarantee All registered users can place bids

Home Page
1. Users will log in

Main success scenario 2. Users will place bids
[Registered users] [Visitors]
3. Users will pay bid fee that is refundable
Authentication Registration
[Check Parameters] [Check Parameters]

Extension User may help each other to identify fake bids
[Invalid] [Invalid]
Special requirement [Valid] Seller registration is required[Valid]
[Admin] [Buyer] [Mechanic]

[seller]
Sale Vehicle Buy Vehicle
Comment Vehicle
Manage Ads Manage Bids Condition
Frequency of occurrence Whenever user want to place bids
Browse choice
Upload Vehicle
Information (Vehicle)
Change Ads
Finalize Send Bid Info

Bids (SMS/Email)
View Vehicle Put
Table: 4.2.14 PlaceSale
Bids (For Registered
Info
Users) Request
Normally
Advertise
Bid Vehicle
4.3 Activity Diagram
Vehicle
Pay For Search inform User

Advertisement Mechanic (SMS/ Email)
UIIT, PMAS, UAAR, 2011 Feedback Page 41

Table: 4.3.1 Activity Diagram
4.4 Domain Model Diagram

Fig. 4.4.1 System Domain Model
4.5 Sequence Diagrams

The system has following sequencing
4.5.1 Searching Vehicle

<< UI >> search:

Buyer Database
Browser page
search_request get_search_page
page_rendered
view_vehicle_info
get_vehicle_info
vehicle_not_found
info_rendered return_vehicle_info
Fig: 4.5.1 Sequence of Sequence of Searching Vehicle

<< UI >> registration: user:

Browser Database
page thevisitor
visitor
Reg_request()
get_reg_form
Return_form
submit() check _parameters() add_user()
invalid _parameters
user_registered user_added()
Fig: 4.5.2 Sequence of User Registration
4.5.3 View Vehicle History

<< UI >> search:

User Database
Browser page
search_request(url) get_search_page()
page _rendered
view_bidding_history()
get_bidding_details()
history_rendered
return_biding_details
Fig: 4.5.3 Sequence of View Bidding History
4.5.4 Admin Log In (Admin has super rights)

Authorized << UI >> << UI >>

user:theuser Database
User Browser Login_page
login_request
Return_form
check _parameters
submit
match_password
invalid _parameters password_not_matched
logged_in password_matched
Fig: 4.5.4 Sequence of Admin Log In
4.5.5 Managing Advertisements

<< UI >>
ads:adspage Database
Browser
Administrator
manage_ads
get_ads_page
page _rendered
post_ads save_ads_info
ads_posted saved_ads_info
remove_ads
ads_removed
Fig: 4.5.5 Sequence of Managing Advertisements
4.5.6 Managing Bids

<< UI >>
bids:page user:the buyer Database
Browser
Administrator
manage_bids
get_bids_page
page _rendered
finalize_bid save_bid_info
bid_ends bid_info_saved
remove_bid
delete_bid_info
bid_removed delete_bid_info
inform_seller & buyer send _SMS/Email
informed_seller & buyer SMS/Email_sent
Fig: 4.5.6 Sequence of Managing Bids
4.5.7 Managing Forums

<< UI >>
forum:page Database
Browser
Administrator
manage_forum
get_forum_page
page _rendered
post_message save_message
message_posted message_saved
remove_message delete_message
message_removed message_deleted
Fig: 4.5.7 Sequence of Managing Forums
4.5.8 User Feedbacks

<< UI >>
forum:page Database
Browser
Registered user
feedback_request
get_feedback_page
page _rendered
post_message save_message
message_posted message_saved
remove_message delete_message
message_removed message_deleted
Fig: 4.5.8 Sequence of User Feedback
4.5.9 Vehicle Inspection (Mechanic’s Module)

<< UI >> search:

Buyer Database
Browser page
vehicle_comments get_comments_page
page_rendered
post_comments save_comments
posted_comments comments_saved
Fig: 4.5.9 Sequence of Vehicle Inspection
4.5.10 Selling Vehicle

<< UI >> vehicle_info:

Seller page user:the buyer user:the mechanic Database
Browser
sale_vehicle get_sale_page
page _rendered
upload_vehicle_info save_vehicle_info
vehicle_info_saved
System
inform_buyer (SMS/Email) Generated
(automatic)
search_mechanic get_mechanic_info
mechanic_info_rendered return_mechanic_info
Fig: 4.5.10 Sequence of Selling Vehicle
4.5.11 Buying Vehicle

<< UI >> vehicle_info: vehicle:

Buyer page user:the seller Database
Browser the vehicle
buy_vehicle search_vehicle
page _rendered
view_vehicle_info check_parameters get_vehicle_info
vehicle_info_returned
System
Generated
inform_seller (SMS/Email) (automatic)
rate_mechanic store_mechanic_rating
rating_assigned
Fig: 4.5.11 Sequence of Buying Vehicle
4.5.12 Put Buy Request

<< UI >> search:

Buyer Database
Browser page
search_vehicle get_search_page
page_rendered
put_request save_request
posted_vehicle_request request_saved
Fig: 4.5.12 Sequence of Put Buy Request
4.5.13 Placing Bid

<< UI >>
User bids:bidspage payment:pay Database
Browser
bid_request
get_bids_page
page _rendered
place_bid make_payment save_bid_info
Refundable
if bid fails
bid_placed payment_verified saved_bid_info
Fig: 4.5.13 Sequence of Placing Bids
4.5.14 Placing Advertisements

<< UI >>
User ads:adspage payment:pay Database
Browser
advertisement_request
get_ads_page
page _rendered
place_ads make_payment save_ads_info
ads_placed payment_verified saved_ads_info
Fig: 4.5.14 Sequence of Placing Advertisements
4.6 Class Diagram

User
Advertisement
- ID : int
- Email : String
- LoginStatus : String
1..* Place * - Ad_ID : int
- Posted_date : Date
+ varifyLogin() : bool
+ search()
+ viewProfile() + place_add()
+ feedback() + post_add()
All Classes have + remove_add()
CRUD operations
like
Insert,Update, <<extends>>
Delete etc
Visitor Mechanic Seller/Buyer

Admin
- ID : int
- Name : String - Name
- Name : String - adminName : String
- Password : String - Password : String
- Password : String
- PhoneNo : int - PhoneNo : int
- Location : string 1 - CreditcardInfo :String
1
+ search_vehicle() + login() - Charges : int
+ ViewHistory() + manageBid()
+ register()
manage
* + manageForum() + login()
+ manageProfile() + checkVehicle() + login()
1..* + manageVehicle() + comments() 1..* + add_profile() *
1..*
+ update_Profile()
+ buy()
+ sale()
1 0..* + bid()
View
1..*
1..*
1..*
Bid
Forum
History
check
- Subject : String - BidID : int
- Postedby : String - BidAmount : int
- History(Sale) manage - PostedDate : Date 0..* - OwnerID : int
- History(Purchase) 0..* - Date : Date
search - History(Bid) sell/buy
- Time : Date/Time
+ forum_feedback() - BestBid : int
+ post_Comment()
+ View_History() + del_Comment()
+ Vehicle_history()
+ bid_history() + place_bid()
+ view_bid()
+ start_bid()
manage *
+ cancel_bid()
*
+ finalize_bid()
+ close_bid()
+ makePayment()
Vehicle
- * Vehicle_ID : int 1..*

- Image 1
- Model : String
- EngineNo : int 1
- ChassisNo : int
1..* - Registration : String
- Color : String *
- Price : int
+ search()
+ vehicle_Info()
+ advertise()
+ view()
+ mechanic_comment()
Fig. 4.6.1 System Class Diagram

4.7 Entity Relationship Diagram
Fig. 4.7.1 System RE Diagram

4.8 Deployment Diagram
User (Admin, Seller, Buyer, Mechanic)

User PC
Web Browser
Windows OS
HTTP
IIS
Web Server
POP3, SMTP and HTTP

Wi n d o w s
Se r v e r
Server (Mainframe)
E ma i l
Se r v e r
G SM
Fig. 4.8.1 System Deployment Diagram

SMS Gateway
4.9 Operational Contracts


Operation: addUser ()
Cross References: Use Cases: Registration.
Pre-Conditions: User will request for the
registration.
Post-Conditions:
Registration instance reg was created.
reg was associated with the database.
reg can add the values into the
database.
reg can return the message.
4.9.2 Search Vehicle

Operation: searchingVehicle ()
Cross References: Use Cases: Searching
Pre-Conditions: User will request for the vehicle
Search Vehicle.
Post-Conditions:
search was associated with the database.
search can fetch the values from the
database.
search can return the values.
4.9.3 Selling Vehicle

Operation: saleVehicle()
Cross References: Use Cases: Sale.
Pre-Conditions: User will request for the Sale
Vehicle.
Post-Conditions:
sale was associated with the database.
sale can add the values into the database.
sale can return the message.

4.9.4 Buying Vehicle

Operation: buyVehicle()
Cross References: Use Cases: Buy.
Pre-Conditions: User will request for the Buy
Vehicle.
Post-Conditions:
buy was associated with the database.
buy can fetch the values into the
database.
buy can return the message.
4.9.5 Sending Email/SMS

Operation: sendEMail()
Cross References: Use Cases:SendEMail.
Pre-Conditions: User will request for the Send
EMail.
Post-Conditions:
SendEMail instance sendm was created.
sendm was associated with the database.
sendm can add the values into the
database.
Server can send the message/mail.
4.9.6 Put Buy Request

Operation: putRequest()
Cross References: Use Cases: Put Buy Request.
Pre-Conditions: User will request for the Put Buy
Request.
Post-Conditions:
request was associated with the database.
request can add the values into the
database.

request can return the message.
4.9.7 Placing Bid

Operation: vehicleBidding()
Cross References: Use Cases: Place Bid.
Pre-Conditions: User will request for the Place Bid.
Post-Conditions:
bid was associated with the database.
bid can add the values into the database.
bid can return the message.
4.9.8 Place Advertisement
Operation: placeAdvertisement()
Cross References: Use Cases: Place Ads.
Pre-Conditions: User will request for the Place Ads.
Post-Conditions:
ads was associated with the database.
ads can add the values into the
database.
ads can return the message.
4.9.9 Vehicle Inspection

Operation: inspectVehicle ()
Cross References: Use Cases: Vehicle Inspection.
Pre-Conditions: User will request for the Vehicle
Inspection.
Post-Conditions:
incpct was associated with the database.
incpct can add the values into the database.
incpct can return the message.

Chapter 5
IMPLEMENTATION
This section includes explanation of different models of the system.
5.1 User Registration

Registration is provided in some cases e.g. when user wants sale, buy, place bid, place
ad etc. User can easily register through Website by filling up a simple registration
form. Before inserting the values into the database Online Verification of Email
address and password will be made to identify the fake Email addresses.
5.2 Selling/ Buying a Vehicle

To sale the vehicle user have to provide detailed information of the
vehicle as well as photos. Whenever any user want to buy the
vehicle seller will be informed by Email/SMS. On the other hand
buyer will also be informed about seller through Email/SMS.
5.3 Put Request

If users can’t find vehicle of their choice they can put request of a
particular choice. Whenever the desired vehicle will be available
they will be informed by SMS/Email.
5.4 Vehicle Inspection

Users can get inspection of their vehicles by authorized vehicle
mechanic. It’s optional for the sake of reliability & customer
satisfaction. It also increases the sale chances.
5.5 Place Bid

The system also provides the facility of bidding. Users can place
bids. Bids will be offline
5.6 Place Advertisements

Users can place advertisements on the site. Multiple types of
advertisements can be placed such as vehicle for sale, vehicle
required, general ads etc
5.6 Sending Email/SMS

This module have is not directly accessible. This will be used by
system automatically when required
5.7 Web component

Web component is implemented in 3 layers. We used three layer
architecture to achieve effective design that provides (when
compared to the two layer) increased performance, flexibility,
maintainability, reusability, and scalability, while hiding the
complexity of data processing from the user.
• Presentation Layer
• Business Logic Layer
• Data Access Layer
5.7.1 Presentation Layer

This is the top most level of the application. The presentation layer
displays information related to such services as displaying
information user interaction wit the system taking inputs from the
user and displaying outputs to the user.
5.7.2 Business Logic Layer

It controls applications functionality by performing detailed

processing. The Validations, Inter mediate Processing and requests
send to database for processing comes under Business Logic layer.
It takes inputs from presentation layer apply interpret it apply any
necessary business logic and then call data access layers methods
for further processing it takes the results from data access layer
again and pass it to the presentation layer for displaying g it to the
user.
5.7.3 Data Access Layer

(DAL) is a layer of a computer program which provides simplified
access to data stored in persistent storage of some kind, such as an
entity-relational database.
DAL might return a reference to an object (in terms of object-
oriented programming) complete with its attributes instead of a row
of fields from a database table. This allows the client (or user)
modules to be created with a higher level of abstraction. This kind of
model could be implemented by creating a class of data access
methods that directly reference a corresponding set of database
stored procedures.

Chapter 6
SOFTWARE TESTING
6.1 TEST PLAN
A test plan documents the strategy that will be used to verify and
ensure that a product or system meets its design specifications and
other requirements.
6.1.1 INTRODUCTION
This document is a high-level overview defining our testing strategy

for the SayVoice System. Its objective is to communicate project-
wide quality standards and procedures. The primary focus of this
plan is to ensure that the SayVoice System will provide better and
secure performance to the user. The project will have three levels of
testing, Unit, System/Integration and Acceptance Testing. We will
utilize testing criteria under the white box and system-testing
paradigm. This paradigm will include, but is not limited to, the
testing criteria, methods, and test cases of the overall design.
Throughout the testing process we will be applying the test
documentation specifications described in the IEEE Standard 829-
1983 for Software Test Documentation.
TEST OBJECTIVES
The main objective of our test plan is to find and report as many
errors and bugs as possible to improve the performance of our
System. SayVoice System has four main components.
SMS to Email conversion, Email to SMS conversion, WEB to mobile
chat and text to voice conversion. Two components (Web to Mobile
chat and Text to Voice converter) has Graphical user interface

6.2 Testing Process

6.2.1 Organize Project:
Organize your project for test according to the following criteria.
6.2.1.1 Schedule
The following tentative schedule will hopefully meet:

Test design (this document) is expected to be completed by 18-07-
2011
Test execution is expected to last no more than two weeks and to
start immediately after the test plans have been approved.
Producing the Test Incident/Summary report is expected to be

completed within 2 days of completing the test execution phase
6.2.1.2 Test Approach/Strategy
We will use unit, integration, system, recovery, security and

acceptance testing for our SayVoice System. Each Test Case will be
prioritized as High, Medium and Low Priority and then scheduled
accordingly. Exceptions to this general rule might include instances
where:
• A large number of low priority test cases can be executed
using a small amount of resources
• A lower priority test is a pre-requisite of another higher
priority test e.g. an expensive and high priority usability test
might necessitate many of the inexpensive low priority
navigational tests to have passed
• Due to the lack of comprehensive requirements, navigational
and functional tests may be scheduled first, so as to allow the
testers the opportunity to gain familiarity with the Web site
(thereby also allowing them to developing pseudo
requirements).

Basic metrics will be kept for test effort (i.e. hours), test cases
executed, and incidents. Due to the lack of available tools and time,
no attempt will be made to collect more sophisticated metrics such
as code coverage. The following type of testing will be done:
6.3 Unit Testing:
The goal of unit testing is to isolate each part of the program and
show that the individual parts are correct. Unit testing provides a
strict, written contract that the piece of code must satisfy.
As a result, it affords several benefits.
Unit testing allows the programmer to refractor code at a later date,
and make sure the module still works correctly (i.e. regression
testing). This provides the benefit of encouraging a programmer to
make changes to the code since it is easy for the programmer to
check if the piece is still working properly. Unit testing will be done
for the following units:
• User Registration.
The testing of this unit will ensure that whether the user has
been registered successfully or not.
• Login
The purpose of this unit testing is to ensure that the user
should never buy, sale, place bid without signing in.
• Update Account
The testing of this unit will ensure that whether the user
account has been updated successfully or not.
• Sale Vehicle
The testing of this unit will ensure that whether the vehicle
information has been uploaded successfully or not.
• Put Buy Request

The testing of this unit will ensure that whether the request
has been put successfully or not
• Place Bid
The testing of this unit will ensure that whether the bid has
been placed successfully or not.
• Place Advertisements
The testing of this unit will ensure that either the
Advertisements has been placed successfully or failed.
• Bidding Price
The testing of this unit will ensure that new bid price should
be greater than last price.
• Finalize Bid
The testing of this unit will ensure that the bid should be
finalized and ended.
• Inform to User
The testing of this unit will ensure that either the user has
been informed successfully or not.
• Email sending link

The testing of this unit will ensure that link of user has been
formed successfully or not.
• Sending Email
The testing of this unit will ensure that either the Email has
been sent successfully or not.

• Send SMS
The testing of this unit will ensure that either the SMS has
been sent successfully or not.
• Create Forum Topic

The testing of this unit will ensure that either the new topic
has been posted successfully or not.
• Logout
The testing of this unit will ensure whether user easily logout
from his account or not.
6.4 Integration testing:

Integration testing is the phase in software testing in which
individual software modules are combined and tested as a group. It
occurs after unit testing and before system testing. The tests are
conducted to ensure that the components are integrated to perform
together. All modules are integrated by an incremental approach,
and integration testing of the system is performed follows:
• Integrate account creation module and test that the software
perform login operation accurately and connected properly to
database.

• Integrate updating module and test that the software

performs the updating and data is successfully stored into
database.
• Web to SMS chat is integrated and tests that message is
properly deliver to the user.
• Integrate extracting Email from pop3 server, summary
generation, converting into SMS and sending SMS to test that
mail is successfully send to the user.
• Integrate the text to voice component to test that required
voice is generated or not.
6.5 System testing:

System testing involves the set of tests that the entire system
performs according to specification:
• Functionality Testing
In testing the functionality of the website following should
be tested
Links
1) Internal Links
2) External Links
3) Broken links

Forms
1) Field Validation
2) Error message for wrong inputs
3) Optional and mandatory fields
Database
Testing will be done on database integrity.
• Performance Testing
Performance testing can be applied to understand the web site’s
scalability, or to benchmark the performance in the environment
of third party products such as servers and middleware for
potential purchase.
• Connection Speed
Tested over various networks like Dial Up, ISDN etc
Load:
i. what is the no. of users per time?
ii. Check for peak loads and how system behaves
iii. Large amount of data accessed by user
Stress:
i. Continuous Load
ii. Performance of memory, CPU, file handling etc.
• Security testing
The primary reason for testing the security of a web is to identify
potential vulnerabilities and subsequently repair them.
• Network Scanning
• Vulnerability Scanning
• Password Cracking
• Log Review
• Integrity Checkers
• Virus Detection

6.6 Assigning Responsibilities
Following are the list persons who are responsible for their
assigned tasks.
• Development Manager:
Ensures that proper analysis and planning is done for the unit
testing phase
• Technical Services Manager:
Ensures that proper analysis and planning is done for

performance testing
• Application Test Manager:
Ensures that proper analysis and planning is done for all other
test
6.7 Design/Build System Test
6.7.1 Test Cases

Tested By: Muhammad Qasim

Test Type Unit Testing
Test Case Number OVS0001
Test Case Name Test registration
Test Case
Description This test verifies that all required fields are
entered and entered values are correct and the
user is already not registered or exists.
Item(s) to be tested
1 Registration link whether it is working properly or not
All the required fields(Email, Address, Username, Password,

2
Phone number, CNIC No, Province, City)
Specifications
Expected
Input Output/Result
1)Click on registration link 1)The registration page will be
2) Enter all required fields with opened
correct values and then click on 2)user will successfully registered
register button. and values will be stored in
database
Procedural Steps
User will click on registration link .the registration page will
1
open.
2 Enter the required values with correct data values.
3 Click on register
If already user is not registered than successfully it will

4
registered and message will be displayed.
Table 6.7.1: Test case of User Registration

Tested By: Muhammad Shafiq

Test Case Name Test Login
Test Case In this test case the email address and password
Description of user will be taken from the user and then test
it against valid output. If user exist, account will
be accessed to the user otherwise error message
will be displayed.
1 Email field to check the valid Email address input.
2 Password field.
Specifications
Expected
Input Output/Result
User name and password of the Login will be successful and
registered user . account will be accepted.
Procedural Steps
User will enter his correct User name.
1
2 User will enter his password
3 Click on login
If registered than successfully access his account otherwise

4
error will be displayed
Table 6.7.2: Test case of login


Test Case Name Test Validation
Test Case In this test case tests the validations applied on

Description every text field Entry with numbers in text field
shall result in an error message being displayed
saying "The First Name field will not accept
numbers".
1 Validation check applied on fields of forms.
Validate the fields against numbers, empty field or special

2 characters e.g. ~!@#$%^&*()_:";'{} .
Specifications
Expected
Input Output/Result
Entry in text fields. Values are successfully inserted in
record.
Procedural Steps
User opens the required form to fill.
1
2 User will enter the correct values in all the fields of form.
3 Click on Submit button.
Table 6.7.3: Test case for Validation.


Test Case Name Test update user account
Test Case
Description This test verify that the account of the user is
updated in case of forget the password or change
the password.
1 Password field to check the valid password.
Account is successfully updated or not.

2
Specifications
Expected
Input Output/Result
(1)Enter previous password. Account is successfully updated and
record is successfully inserted in
(2)Enter security question and database.
answer.
Procedural Steps
User will open account updating form.
1
2 User will enter the correct values in all the fields of form.
3 Click on Recover button.
Table 6.7.4: Test case for update user account.


Test Case Name Test Advertise Vehicle
Test Case
This test verify that the record of selling vehicle is
Description
inserted successfully in database and make sure
that all the fields filled correctly and no field will
be empty.
1 Insertion of record of selling vehicle.
2 Validate all the fields.
Specifications
Expected
Input Output/Result
(1)Click to sale vehicle from menu. Account is successfully updated.
(2)Enter correct values in all the Record is inserted in database.

fields of form and click on Save
button.
Procedural Steps
User will click on sale link.
1
2 Enter the required values with correct data values.
3 Click on Save button.
4 Message of successful record insertion.
Table 6.7.5: Test case Advertise Vehicle.


Test Case Name Test Search Vehicle
Test Case
Description
In this test case make sure that desired vehicle is
searched successfully within specifications.
1 Searching of desired vehicle.
Specifications
Expected
Input Output/Result
Type specifications of desired Search is successful.
vehicle.
Procedural Steps
User will click on search link.
1
2 Enter correct specification of desired vehicle.
3 Click on Search button.
Table 6.7.6: Test case Search Vehicle.


Test Case Name Test Vehicle Inspection
Test Case
Description
This test verifies that the vehicle is selected to
get inspection from an authorized mechanic.
1 Vehicle is selected to get inspection.
2 Record of particular vehicle from database.
Specifications
Expected
Input Output/Result
(1)Click to Vehicle Inspection link. Comments of mechanic successfully
inserted in database of particular
(2)Enter correct comments about vehicle.
vehicle after inspecting the
particular vehicle.
Procedural Steps
Mechanic will click inspection link.
1
2 Check the vehicle.
3 Enter correct inspection detail about vehicle.
Table 6.7.7: Test case Vehicle Inspection.


Test Case Name Test Place Bids
Test Case
Description
This test verifies that the user can place bid
within limited time.
1 Update profile of vehicle to bid.
2 Record of user.
Specifications
Expected
Input Output/Result
(1)Click to place bid link. Vehicle profile is updated and bid is
placed successfully.
(2)Enter Vehicle details.
(3)Time and date of expiring bid.

Procedural Steps
User will click on place bid link from menu.
1
2 Enter detail of vehicle.
3 Enter bidding price.
Table 6.7.8: Test Case Place Bid.


Test Case Name Test Bidding Price
Test Case
This test verifies that the price of bidding of
Description
vehicle must be greater than the last bid price
otherwise error will be generated of unsuccessful
bidding.
1 Vehicle to place a bid.
2 Check last entered bid price.
3 Bid is finalized or not.
Specifications
Expected
Input Output/Result
(1)Select bidding vehicle. Bid price is entered correctly.
(2)Enter correct bid price.
(3)Finalize bid.
Procedural Steps
User will click on available bids link from menu.
1
2 Enter price of bid.
Table 6.7.9: Test Case Bidding Price.


Test Case Name Test Finalize Bid
Test Case
This test verifies that the bid is finalized of
Description
particular vehicle successfully otherwise error will
be generated due to expiring bid or any other
reason.
1 Vehicle to place a bid.
2 Check last entered bid price.
4 Check expiring date and time of bidding.
Specifications
Expected
Input Output/Result
(1)Select bidding vehicle. Bid price is entered correctly and
bid is finalized successfully and
(2)Enter correct bid price. user. Congratulation message will
be displayed.
(3)Finalize bid.
Procedural Steps
User will click on available bids link from menu.
1
2 Enter price of bid.
3 Finalize the bid.
4 Contact to the seller.
Table 6.7.10: Test Case Finalize Bid


Test Case Name Test Inform to User
Test Case
Description This test verifies that the user is informed after
buying a vehicle, selling a vehicle or finalizing
bid. User can be seller, buyer or bidder.
1 Check status of Vehicle.
2 Check Vehicle is not sold already.
4 Check expiring date and time of bidding.
Specifications
Expected
Input Output/Result
(1)Select Vehicle to buy or the Confirmation message will be
bidding vehicle. displayed and both the users will be
informed instantly.
(2)Enter correct bid price.
(3)Finalize bid.
Procedural Steps
User will click on vehicle available to purchase.
1
2 Click on buy.
3 Click on more detail.
4 View detail of vehicle.
5 Click on Confirm button.
Table 6.7.11: Test Case Inform to User.


Test Case Name Test Mail Server
Test Case
Description This test verifies that the Mail Server is
successfully connected to send the confirmation
email to appropriate users.
1 Connection to the internet to access the mail server.
2 Connection to database.
3 Select appropriate person to send the mail.
Specifications
Expected
Input Output/Result
Confirm the user to send email. Email is successfully generated from
System.
Procedural Steps
User will perform the sale or purchase activity.
1
2 Confirm that activity.
Table 6.7.12: Test Case Mail Server.


Test Case Name Test Sending Email
Test Case
Description
This test verifies that whether the Email is
successfully sent to the relevant person or not.
1 Detail of the users.
2 Email is sent successfully to relevant person.
Specifications
Expected
Input Output/Result
Confirm the user to send email. Email is successfully sent from the
Arrival of Email. System to appropriate user to
inform.
Procedural Steps
User will perform the sale or purchase activity.
1
2 Confirm that activity.
3 Email address will be extracted from the databases.
5 Email will be send to the appropriate person.
Table 6.7.13: Test Case Sending Email.


Test Case Name Test Send SMS
Test Case
Description This test will verify that the SMS will send by the
System to inform the users Without any error.
1 Receiving SMS from GSM device.
2 SMS is generated by the system.
3 SMS is received by the relevant person.
Specifications
Expected
Input Output/Result
SMS is sending by the connected SMS is successfully sent.
GSM device.
Procedural Steps
GSM will send the SMS
1
2 SMS will send to the relevant person.
Table 6.7.14: Test Case Send SMS.


Test Case Name Test Create Forum Topic
Test Case
This test will verify that whether the Topic of
Description
discussion forum is successfully created without
any error.
1 Create the topic in discussion forum.
2 Topic is relevant to the problem.
3 Topic is posted successfully.
Specifications
Expected
Input Output/Result
User will post the discussion topic. Topic is successfully posted on the
discussion forum.
Procedural Steps
User will Select the Forum link from menu.
1
2 Create title of Topic.
Table 6.7.15: Test Case Create Forum Topic.


Test Case Name Test Place Advertisement
Test Case
Description This test will verify whether the advertisement
placed by any registered user is done or not.
1 User login or not.
2 Advertisement is placed.
Specifications
Expected
Input Output/Result
User will place the advertisement. Advertisement is successfully
placed.
Procedural Steps
User will Select the Place Advertisement link from menu.
1
2 Place advertisement title.
3 Select images for advertisement.
Table 6.7.16: Test Case Place Advertisement.


Test Case Number SV0017
Test Case Name Test logout
Test Case
Description This test case will specify the functionality of the
logout function that user click on logout button
and he will successfully logout from his account.
1 Logout button
Specifications
Expected
Input Output/Result
Click on logout button Users will logout successfully and
session will be expired.
Procedural Steps
User will click on logout button
1
2 The session will expire
3 User will logout successfully
Table 6.7.17: Test case of Logout
6.8 Design/Build Test Procedures
6.8.1 Build Test Environment
The following elements are required to support the overall testing

effort at all levels.

The SayVoice system is tested at University Labs with the required

software requirement.
Software:
OS Window XP
Visual Stdio.net 2008
Microsoft SQL Server 2005
Sony Ericsson PC Suite
Internet Explorer 6, Mozilla FireFox 3.5
Hardware: GSM Device (SONY ERICSSON W580i)

Dell GX 270 (2.8MHz, 512 MB RAM, 80 GB Hard disk)
6.9 Execute System Tests
6.2.5.1 Test case execution

Software: Online Vehicle Showroom
Modulation: User Registration
Test Name: Test Registration
Test ID: OVS0001
Test Description: This test verifies the Email, Address, Username,
Password, Phone number, CNIC No, Province, City to create their
account.
Test Case ID Test Input Expected Actual Result

Result

OVS0001 Email address is a Prompt that Prompt that

required field try to enter email enter email
enter a record except address address
email address
OVS0001 Username field is a Prompt that Prompt that
required field try to enter your enter your
enter all fields except Username. Username
Username
OVS0001 Try to enter string Prompt that Prompt that
values in Phone enter your enter your
number field integer values integer values
OVS0001 Minimum limit of Prompt that Prompt that
password length is 8 enter minimum enter minimum
try to enter less than 8 character in 8 character in
8 digits length length
OVS0001 Verify that address Prompt that Prompt that
field is required field enter address it enter address it
by keeping this field is required. is required.
empty.
OVS0001 Enter all fields except Prompt that Prompt that
the CNIC No and click select CNIC No select CNIC No
on submit from given it is from given it is
required required
OVS0001 All field values are Prompt you are Prompt you are
correct registered Register

Modulation: Login
Test Name: Test Login
Test ID: OVS0002
Test Description: This test verifies the Username and Password of
the users to access their account.

Result
OVS0002 Enter your Username The Username The Username
in username field and will be accepted will be accepted
click login
OVS0002 Enter only password Prompt that Prompt that
keep the Username enter your enter your
field empty and click Username Username
login
OVS0002 Enter only Username Prompt that Prompt that
and keep the enter your enter your
password field empty. password password
and click login
OVS0002 Enter wrong password Prompt that Prompt that
and click login password is password is
wrong wrong
OVS0002 Enter wrong Prompt that Prompt that
Username and click user is not user is not
login registered. registered.

Modulation: Check Validation
Test Name: Test Validation
Test ID: OVS0003
Test Description: This test verifies to make sure that all the fields
filled correctly and no field will be empty.
.

Result
OVS0003 Enter numeric valued Prompt that Prompt that
into any text field enter correct enter correct
and click login value in text value in text
field field
OVS0003 Enter only password Prompt that Prompt that
keep the Username enter your enter your
field empty and click Username Username
login
OVS0003 Enter only CNIC No in Prompt that the Prompt that the
text field with string format entered format entered
CNIC No is wrong CNIC No is
wrong
OVS0003 Enter wrong Prompt that Prompt that
password and click password is password is
login wrong wrong
OVS0003 Remains empty any Prompt that text Prompt that text
text field and click field cannot be field cannot be
login blank. blank.

Modulation: Edit User Account
Test Name: Test Update User Account
Test ID: OVS0004
Test Description: This test verifies that the account of the user is
updated in case of forget the password or change the password.
Test Case ID Test Input Expected Result Actual Result

OVS0004 Keep User name field Prompt that the Prompt that the

empty in password Username must Username must

recovery enter enter
OVS0004 Value of Security Prompt that the Prompt that the
Question and Answer security question security
fields are not chosen. and answer must question and
be given to answer must be
update your given to update
account your account
OVS0004 Keep Price field Prompt that enter Prompt that
empty and click on the price of enter the price
Save button vehicle of vehicle
OVS0004 Enter price in price Prompt that the Prompt that the
field with string value string value does string value
not accepted does not
accepted
OVS0004 Click Save button Prompt that all Prompt that all
with all empty fields the fields must be the fields must
of the form fill. be fill.

Modulation: Sale Vehicle
Test Name: Test Advertise Vehicle
Test ID: OVS0005
Test Description: This test verify that the record of selling vehicle is
inserted successfully in database and make sure that all the fields
filled correctly and no field will be empty.

Result
OVS0005 Not selected any Prompt that Prompt that

value from dropdown select values select values

list and click Save. from dropdown from dropdown
list list
OVS0005 Enter value of Prompt that Prompt that
Mileage field in string enter numeric enter numeric
value for value for
mileage mileage
OVS0005 Keep Price field Prompt that Prompt that
empty and click on enter the price enter the price
Save button of vehicle of vehicle
OVS0005 Enter price in price Prompt that the Prompt that the
field with string value string value does string value
not accepted does not
accepted
OVS0005 Click Save button Prompt that all Prompt that all
with all empty fields the fields must the fields must
of the form be fill. be fill.

Modulation: Search
Test Name: Test Search Vehicle
Test ID: OVS0006
Test Description: In this test case make sure that desired vehicle is
searched successfully within specifications.

Result
OVS0006 Keep empty search Prompt that no Prompt that no

textbox item is selected item is selected

OVS0006 Enter special Prompt that no Prompt that no
characters in text item is match item is match
field
OVS0006 No connectivity to Prompt that no Prompt that no
database item is found item is found

Modulation: Mechanic
Test Name: Test Vehicle Inspection
Test ID: OVS0007
Test Description: This test verifies that the vehicle is selected to get
inspection from an authorized mechanic.

Result
OVS0007 Keep empty field of Prompt that Prompt that
General Condition of condition must condition must
vehicle be selected be selected
OVS0007 Click on Save button Prompt that Prompt that
without selecting Engine Condition Engine

engine condition is not selected Condition is not

selected
OVS0007 Keep the field empty Prompt that Prompt that
of Mileage textbox enter the value enter the value
of mileage of mileage

Modulation: Bidding
Test Name: Test Place Bids
Test ID: OVS0008
Test Description: This test verifies that the user can place bid within
limited time.

Result
Price of vehicle Enter the price Enter the price
of bid of bid
OVS0008 Click on Save button Prompt that all Prompt that all
without selecting any the fields must the fields must
field be selected be selected
OVS0008 Enter value of price Prompt that Prompt that
in string price in string price in string

cannot be cannot be
accepted accepted
OVS0008 Enter numeric value Prompt that Prompt that
in Color textbox enter correct enter correct
color of vehicle color of vehicle

Modulation: Bidding
Test Name: Test Bidding Price
Test ID: OVS0009
Test Description: This test verifies that the price of bidding of
vehicle must be greater than the last bid price otherwise error will
be generated of unsuccessful bidding.

Result
Bidding Price of Must enter the Must enter the
vehicle price price
OVS0009 Enter price less than Prompt that Prompt that all
price of last bid price must be the fields must
greater than last be selected
bid placed

cannot be cannot be
accepted accepted

Modulation: Bidding
Test Name: Test Finalize Bid
Test ID: OVS0010
Test Description: This test verifies that the bid is finalized of
particular vehicle successfully otherwise error will be generated due
to expiring bid or any other reason.

Result
Bidding Price of Must enter the Must enter the
vehicle price price
OVS0010 Enter price less than Prompt that Prompt that all
price of last bid price must be the fields must
greater than last be selected
bid placed

cannot be cannot be
accepted accepted

Modulation: Bidding
Test Name: Test Inform to User
Test ID: OVS0011
Test Description: This test verifies that the user is informed after
buying a vehicle, selling a vehicle or finalizing bid. User can be
seller, buyer or bidder.

Result
OVS0011 Keep empty fields of Prompt that all Prompt that all
form of vehicle fields must be fields must be
bidding filled filled
OVS0011 Close without click on Prompt that Prompt that
Save button bidding is not bidding is not
finalized finalized
OVS0011 All fields are entered Configuration Bidding saved
and finalized
correctly and click on will be saved
successfully.
Save button


Modulation: Email
Test Name: Test Mail Server
Test ID: OVS0012
Test Description: This test verifies that the Mail Server is
successfully connected to send the confirmation email to
appropriate users.

Result
OVS0012 Email Server Prompt that Prompt that
Connection Server is not Server is not
found found
OVS0012 Keep some fields Prompt that all Prompt that all
empty and click on fields must be fields must be
save filled filled


Modulation: Email
Test Name: Test Sending Email
Test ID: OVS0013
Test Description: This test verifies that whether the Email is
successfully sent to the relevant person or not.

Result
OVS0013 Arrival of an Email Email will sent to Email will sent
the user to the user
successfully successfully
OVS0013 Keep some fields Prompt that all Prompt that all
empty and click on fields must be fields must be
save filled filled


Modulation: SMS
Test Name: Test Send SMS
Test ID: OVS0014
Test Description: This test will verify that the SMS will send by the
System to inform the users without any error.

Result
OVS0014 Select all values from New New

dropdown lists and configuration of configuration of
click on connect GSM will be GSM will be
button saved saved
OVS0014 Select all values Prompt that Prompt that
except COM port selects COM selects COM
port. port.
OVS0014 Click on Connect Configuration Configuration
will successfully successfully
make. saved.
OVS0014 Click on Disconnect All newly made All newly made
changes will changes discard
discard
OVS0014 Click on Send Button SMS will be sent SMS will be sent


Modulation: Forum
Test Name: Test Create Forum Topic
Test ID: OVS0015
Test Description: This test will verify that whether the Topic of
discussion forum is successfully created without any error.

Result
OVS0015 Type title of Forum in Prompt that the Prompt that the
numeric value Forum topic Forum topic
must be in string must be in
string
OVS0015 Click on Post button Prompt that Prompt that
without giving title Topic Title must Topic Title must
name of forum be entered be entered
OVS0015 Click on Post button Forum topic is Forum topic is
posted posted


Modulation: Advertisement
Test Name: Test Place Advertisement
Test ID: OVS0016
Test Description: This test will verify whether the advertisement
placed by any registered user is done or not.

Result
OVS0016 Click on Prompt that you Prompt that you
Advertisement must login must login
without login before place an before place an
advertisement. advertisement.
OVS0016 Click on Save button Prompt that title Prompt that title
without title must be entered must be entered
OVS0016 Click on Save button Prompt that the Prompt that the
with numeric value in numeric value numeric value
title text field cannot be cannot be
accepted accepted
OVS0016 No images selected Prompt that click Images are
for advertisement on Browse selected for
button to select advertesement
images


Modulation: Logout
Test Name: Test Logout
Test ID: OVS0017
Test Description: This test will verify that after clicking on Logout
Link Button the Session will Expire and user will successfully logout.
Test Case ID Test Input Expected Result Actual Result

OVS0017 User will click on Session will Expire Session Expires
Logout Button and user will and user
successfully logout successfully
and logout link logout and
Button will be logout link
invisible. Button become
invisible.
OVS0017 User will click on The user will not be The user not
any other Link logged out logged out.
Button instead of
logout
6.10 Test output Analysis

We have analyzed the output of all the test cases in detail. The test
output analysis revealed the following:
Test summary
Deviation
6.10.1 Test Summary
The objective of this test is to demonstrate the performance of the

software. System meets all the requirements. All modules have
been successfully unit tested in first phase. Then the modules are
integrated to perform integration testing. The performance of
integrated system is according to the client’s specification. Finally
the system is fully tested for the system testing, recovery,
performance and security testing.
6.10.2 Deviation
No deviation found in system during testing.
6.11 Bug Reports:

YOUR COMPANY’S NAME Car Point PROBLEM

REPORT#_____1_____
PROGRAM Online Vehicle Showroom (send Email / Message)

RELEASE 1st VER 1.0
REPORT TYPE (1-6) ___2__ SEVERITY (1-3) __3___ ATTACHMENTS(Y/N)

___NO_____
1. Coding issue 4. Documentation 1. Fatal If yes.
Describe:
2. Design issue 5. Hardware 2.Serious
_____________________
3. Suggestion 6. Query 3. Minor
_____________________
PROBLEM SUMMARY_ send messages is not properly received but showing the
message that it is send successfully
CAN YOU REPRODUCE THE PROBLEM? (Y/N) Yes
PROBLEM AND HOW TO REPRODUCE

Send Email to relevant person
Send any message to any mobile number
SUGGESTED FIX
Check proper connectivity of GSM device / Mail Server.
REPORTED BY: Muhammad Shafiq DATE 20/06/2011

ITEMS BELOW ARE FOR USE ONLY BY THE DEVELOPMENT

TEAM
FUNCTIONAL AREA User Account Updation

ASSIGNED TO Muhammad Qasim
STATUS (1-2) __Closed__
1. Open 2.Closed
RESOLUTION (1-9) _Fixed_____ RESOLUTION

VERSION_______________
1. Pending 4. Deferred 7.Witdraw by reporter

2. Fixed 5. As designed 8. Need more info
3. Irreproducible 6. Can’t be fixed 9. Disagree with suggestion
RESOLVED BY Muhammad Qasim DATE 21/06/2011
RESOLUTION TESTED BY Muhammad Qasim DATE 21/0/2011
TREAT AS DEFERRED (Y/N) ____No__________

REPORT#_____3_____

PROGRAM Online Vehicle Showroom (User Account)
RELEASE 1st VER 1.0

___NO_____
1. Coding issue 4. Documentation 1. Fatal If yes. Describe:

_____________________
_____________________
PROBLEM SUMMARY_ Alignment of text fields in web to SMS chat module is not
justified which does not give good impression?
CAN YOU REPRODUCE THE PROBLEM? (Y/N) NO
REPORTED BY: Muhammad Qasim DATE

21/06//2011
ITEMS BELOW ARE FOR USE ONLY BY THE DEVELOPMENT TEAM

FUNCTIONAL AREA Send SMS / Email ASSIGNED TO Muhammad

Qasim
STATUS (1-2) ___Closed____
1. Open 2.Closed
RESOLUTION (1-9) __fixed____ RESOLUTION VERSION___1.0__

RESOLUTION TESTED BY Muhammad Shafiq DATE 21/06/2011
TREAT AS DEFERRED (Y/N) ___No___________

REPORT#_____2_____
PROGRAM Online Vehicle Showroom (Update User Account)

RELEASE 1st VER 1.0

___NO_____

1. Coding issue 4. Documentation 1. Fatal If

yes. Describe:
_____________
_____________
PROBLEM SUMMARY_ Stored procedure written for updating users is not

implemented with certain standards and it overwrite those values by NULL which are not
supplied by the user.
CAN YOU REPRODUCE THE PROBLEM? (Y/N) Yes
Overwriting the values by NULL which are not supplied by the user. Sign in into the
website and try to change your info leave one or two text fields empty and click on save
button. The values of empty fields will be overwritten by NULL.
REPORTED BY: Muhammad Shafiq DATE 21/06/2011

FUNCTIONAL AREA Bidding ASSIGNED TO Muhammad

Shafiq
STATUS (1-2) ____Closed___
1. Open 2.Closed
RESOLUTION (1-9) __Fixed____ RESOLUTION

VERSION_______________

RESOLVED BY : Muhammad Shafiq DATE 21/06/2011
RESOLUTION TESTED BY: Muhammad Qasim DATE 21/06/2011
TREAT AS DEFERRED (Y/N) _________No_____

REPORT#_____4_____

PROGRAM Online Vehicle Showroom (Documentation)
RELEASE 1st VER 1.0
REPORT TYPE (1-6) ___4__ SEVERITY (1-3) __1___ ATTACHMENTS (Y/N)

___NO_____

_____________________
_____________________
PROBLEM SUMMARY
Font type and Size of same level of heading is not consistent through out the project
report which does not look nice.
CAN YOU REPRODUCE THE PROBLEM? (Y/N) No
SUGGESTED FIX
Use same font type and size for same level of headings.
REPORTED BY Muhammad Shafiq DATE 21/06/2011

FUNCTIONAL AREA Search ASSIGNED TO Muhammad

Shafiq
STATUS (1-2) ____Closed___
1. Open 2.Closed

VERSION_______________

RESOLVED BY: Muhammad Shafiq DATE 22/06/2011
RESOLUTION TESTED BY: Muhammad Qasim DATE 22/06/2011
TREAT AS DEFERRED (Y/N) _________No_____

REPORT#_____4_____

RELEASE 1st VER 1.0

___NO_____

_____________________
_____________________
PROBLEM SUMMARY
Font type and Size of same level of heading is not consistent through out the project
report which does not look nice.
SUGGESTED FIX
Use same font type and size for same level of headings.
REPORTED BY Muhammad Qasim DATE 22/06/2011

FUNCTIONAL AREA Documentation ASSIGNED TO

Muhammad Shafiq
1. Open 2.Closed

VERSION_______________

RESOLVED BY Muhammad Shafiq DATE 22/06/2011
RESOLUTION TESTED BY Muhammad Qasim DATE 22/06/2011
TREAT AS DEFERRED (Y/N) ______No________

REPORT#_____6_____

RELEASE 1st VER 1.0

___NO_____

_____________________
_____________________
PROBLEM SUMMARY_
User guide is not given or attached with the documentation.
SUGGESTED FIX
Provide user Guide with the documentation

FUNCTIONAL AREA Documentation ASSIGNED TO

Muhammad Qasim
1. Open 2.Closed

VERSION_______________

RESOLUTION TESTED BY Muhammad Shafiq DATE 23/06/2011

YOUR COMPANY’S NAME Voice mates PROBLEM

REPORT#_____6_____
PROGRAM Online Vehicle Showroom (Advertisement) RELEASE 1st

VER 1.0

___NO_____

_____________________
_____________________
PROBLEM SUMMARY_
Summary is also generated for an Email having less than 160 words.
SUGGESTED FIX

FUNCTIONAL AREA Forum Message ASSIGNED TO Muhammad Qasim
1. Open 2.Closed

VERSION_______________

RESOLVED BY : Muhammad Qasim DATE 23/06/2011
RESOLUTION TESTED BY: Muhammad Shafiq DATE 23/06/2011

Chapter 7
CONCLUSIONS & FUTURE WORK
7.1.1 ACHIEVEMENTS
7.1.2 LIMITATIONS
7.1.3 Future Work
7.1 ACHIEVEMENTS
We feel very proud after development and implementation of our

final project successfully. Before developing through this project
although we have a good theoretical knowledge of software
engineering, being students of computer science, but it is far away
from theory to develop a real life system that completely fulfill the
user requirements. We had a very good interaction with our internal
supervisor; MS. Ayesha Umair she helped us to develop the system
well in time.
During the development of the project we have achieved the
following benefits.
Project management and scheduling
How to interact with the user
System analysis and data collection
A good knowledge of system designing and modeling
Latest tools and technologies
Testing strategies
User documentation
During the modeling phase I learnt Smart Draw for UML.
During testing and implementation finding a bug and its fixture was
totally new and healthy experience. One of the very important
aspects of the project was how to document our project properly. I
have learnt new tools ASP, Visual c#, SQL Server 2008 and Adobe

Photoshop which will help us a long way as we will be starting our

careers as IT professional.
7.2 Limitations
The project is developed keeping in view the research oriented

requirement of a final master project. So it may lack some elegance
or sophistication but we proud that we have worked in a highly
versatile environment and we have taken the right steps towards
the right direction in terms of where the technology is going
nowadays.
7.3 Future Work
Due to the extensibility of project we have some future plan to

extend the project.
• In future OVS system will be converted into RDF based system
i.e. semantic web.
• A PDA based version will be developed.
• In future, system will be able to send voice SMSs.
• In future image recognition will be added in system to
recognize vehicle images.
• In future live bidding will be introduced.
REFERENCES & BIBLIOGRAPHY

References
[1] S. AGUILERA, A. BORRAJO, J.M. PARDO, E. MUÑOZ "Speech

Analysis Based Devices for Diagnosis and Education on Speech and
Hearing Impaired People" Proc. International Conference on
Acoustics, Speech and Signal Processing, ICASSP 86, 641-644 (1986)
[2] S. AGUILERA, J.M. PARDO, A. SANTOS, E.MUÑOZ "Speech Based

Aids for the Blind: Madrid Experience" Communication System for
the Blind, Rainer F. V. Witte (ed) Verlag der Deutschen
Blindenstudienanstalt. V. Marburg /Lahn 1990, pp 140-146
[3] L. BOVES, M. REFICE "The linguistic processor in a Multilingual

Text-to-Speech and Speech-to-text conversion system" Proc. of the
European Conference on Speech Technology, pp 385-388, J. Laver
and M. Jack (ed) CEP Consultants, Edinburg 1987
[4] A. BORRAJO, S. AGUILERA, J.M. PARDO, E. MUÑOZ "An efficient

pitch extraction method for diagnosis and education" Proc.
MELECON-85, Vol I, Bioengineering, 33-36, Madrid 1985.
[5] M.A. BERROJO, J. CORRALES, J. MACIAS, S. AGUILERA "A PC

graphic tool for speech research based on DSP board" Accepted in
the International Conference on Spoken Language Processing ICSPL
-92 Alberta Canada.
[6] J.F. MATEOS, A. MACARRON, S. AGUILERA "A PC card for

rehabilitation of deficient auditive people" Proc. V European Signal
Processing Conference. EUSIPCO -90. 1990.
[7] J. FERREIROS, A. CASTRO, J.M. PARDO "Comparison between two

different approaches in speaker-independent isolated digit
recognition" Proc. of EUROSPEECH 1991
[8] A. GOLDEROS "Reconocimiento de palabras aisladas con

independencia del locutor, aplicación al reconocimiento de dígitos
en español" Tesis doctoral ETSIT-Universidad Politécnica de Madrid,
Septiembre 1983
[9] R.MARTINEZ et al "A spanish talking calculator" Proc. of

EUROMICRO 1978
[10] P.J. MORENO, M. MARTINEZ, J.M. PARDO, J.A VALLEJO

"Improving naturalness in a text to speech system with a new
fundamental frequency algorithm" Proc. Eurospeech 1989, Ed CEP
Consultants Ltd, Vol I, pp 360-363 A
[11] J.C. OLABE, A. SANTOS, R. MARTINEZ, E. MUÑOZ, M. MARTINEZ,

A. QUILIS, J. BERNSTEIN "Real time text-to-speech Conversion

System for Spanish" Proc. of IEEE Int. Conf. on Acoustics Speech and
Signal Processing, pp 2.10.1- 2.10.3 1984
[12] J.M. PARDO "On the application of DSP to speech training for
the deaf" First European Signal Processing Conference EUSIPCO 80,
Lausanne 1980
[13] J.M. PARDO "Vocal Tract Shape Analysis for Children" Proc. Int.
Conf. on Acoustic Speech and Signal Processing. 763-766, IEEE
(1982)
[14] J.M. PARDO, S. AGUILERA, J. OLABE, E. MUÑOZ "Speech

Learning Aid for the Deaf: Results and Design Implications" Signal
Processing II Theories and Applications. 609-612. H.W. Schussler ed.
Elsevier Science. Publishers (1983)
[15] J.M. PARDO "On the Determination of Speech Boundaries: A

Tool for Providing Anchor Time Points in Speech Recognition" Proc.
International Conference on Acoustics, Speech and Signal
Processing ICASSP 86, 2267-2270 (1986)
[16] J.M. PARDO, M. MARTINEZ, A. QUILIS, E. MUÑOZ "Improving

Text-to Speech Conversion in Spanish: Linguistic Analysis and
Prosody" Proc. European Conference on Speech Technology, Vol. 2,
CEP Consultants LTD, 173-176, Edinburgh (1987) A
[17] J.M. PARDO, H. HASAN "Large vocabulary, speaker independent

isolated word speech recognition using Hidden Markov Models" Proc.
Eurospeech 1989, Ed CEP Consultants Ltd Vol II pp 146-149 A
Bibliography
[1] Chiritian Nagel, Bill Evjen, Professional C# 2008.
[2] Bill Evejen,Scott Hanslemen, Proffessional ASP.NET 4 in C# .
http://msdn.microsoft.com/library/default.asp?
url=/library/enus/dnglobspec/html/ws-rm-execsummary.asp
[3] Internet based Distributed Computing Projects

http://www.aspenleaf.com/distributed
Appendix-A USER MANNUAL

Screen Shots

Following are the screen shots of the Say Voice System.

Home
Fig.7.1 System Home Page
Registration Form

Fig.7.2 User Registration Page
Sale Vehicle

Fig.7.3 Vehicle Sale Page
Advertisements

Fig.7.4 Advertisements Page
Put Request

Fig.7.5 Put Request Page
Order Advertisements

Fig.7.6 Order Advertisements
Vehicle Inspection

Fig.7.6 Mechanic Comments
Discussion Forms

Fig.7.7 Discussion Forums

Vehicle System Online

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Vehicle System Online

Încărcat de

Drepturi de autor:

Formate disponibile

Online Vehicle Showroom

MASTER OF COMPUTER SCIENCE

UNIVERSITY INSTITUTE OF INFORMATION TECHNOLOGY

Dedicated to our beloved parents and to all

UIIT, PMAS, UAAR, 2011 Page ii

Project Title : Online Vehicle Showroom

Undertaken By : Muhammad Qasim

Supervised By : Madam Bushra Hameed

Date Started : 15-03-2011

Date Completed : 20-07-2011

Technologies Used : Visual Studio 2008,

Operating System : OS Window XP 2006

Web Server : IIS (Internet Information server)

Hardware Used : GSM Device (SONY ERICSSON W580i)

UIIT, PMAS, UAAR, 2011 Page iii

Thanks to Almighty Allah for giving us knowledge, power and strength

helped us during this project but we are really thankful to Madam

Bushra Hameed from University Institute of Information Technology,

us a lot during the times of difficulties. In the end we would like to

UIIT, PMAS, UAAR, 2011 Page iv

We hereby declare that this software, neither as a whole nor as a part

have developed this software and accompanied report entirely on the

basis of our personal efforts. If any part of this project is proved to be

copied out from any source or found to be reproduction of some other.

We will stand by the consequences. No portion of the work presented

or qualification of this or any other university or institute of learning.

UIIT, PMAS, UAAR, 2011 Page v

University Institute of Information Technology

PMAS - Arid Agriculture University,

For the award of the degree of

MASTER OF COMPUTER SCIENCE

Dated: ______________ Director: ________________________

UIIT, PMAS, UAAR, 2011 Page vi

The “Online Vehicle Showroom System” a web application is

UIIT, PMAS, UAAR, 2011 Page vii

3.2 OVERALL DESCRIPTION......................................................................14

3.3 SYSTEM FEATURES............................................................................17

3.7 OTHER NONFUNCTIONAL REQUIREMENTS...........................................23

UIIT, PMAS, UAAR, 2011 Page viii

UIIT, PMAS, UAAR, 2011 Page ix

1.1.1 User Registration

1.1.2 Selling & Buying Vehicles

1.1.3 Sending Email/SMS

It means that whenever a buyer’s choice not found he/she

1.1.4 Vehicle Bidding

UIIT, PMAS, UAAR, 2011 Page 1

ii. No account management or registration is done for visitors.

iii. If any visitor selects any vehicle to purchase then it will

1.2 PROJECT SCOPE

1.3 PROJECT OBJECTIVES

UIIT, PMAS, UAAR, 2011 Page 2

Following are the main objectives of our system:

ii. Increase website audience.

iv. Photos are automatically resized and optimized.

v. Help includes a step by step Wizard and detailed User Manual.

vi. User account manager

vii. Multiple account types

viii. Customizable account privileges

ix. Support for an unlimited number of vehicles registration in an account.

x. Customizable listing feature fields

xi. Modular code construction for easy site integration

1.4 PROPOSED SOLUTION

UIIT, PMAS, UAAR, 2011 Page 3

Dated: Director: __________