Final Project Documentation

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 CONTENTSPage #

1.INTRODUCTION............................................................................1

UIIT, PMAS, UAAR, 2011 Page vii


1.1 PROJECT OVERVIEW...............................................................1

1.1.1 User Registration.....................................................1

1.1.2 Selleing & Buying Vehicle.......................................1

1.1.3 Sending Email/SMS..................................................1

1.1.4 Vehicle Bidding........................................................2

1.1.5 User Friendly Search...............................................2

1.1.6 Discussion Forum....................................................2

1.1.7 Advertisements.......................................................2

1.2 PROJECT SCOPE....................................................................2

1.3 PROJECT OBJECTIVE...............................................................3

1.4 PROPOSED SOLUTION.............................................................3

1.5 PROPOSED SYSTEM COMPONENTS............................................5

1.6 TOOLS AND TECHNOLOGIES USED............................................6

2.LITERATURE REVIEW....................................................................7

3.REQUIREMENT ANALYSIS.............................................................12

4.SOFTWARE DESIGN......................................................................27

4.1 USE CASE DIAGRAM..............................................................28

4.2 FULLY DRESSED USE CASES....................................................29

4.3 ACIVITY DIAGRAM..................................................................43

4.4 DOMAIN MODEL DIAGRAM......................................................44

4.5 SEQQUENCE DIAGRAMS..........................................................45

4.6 CLASS DIAGRAM...................................................................59

4.7 ENTITY RELATIONSHIP DIAGRAM...............................................60

4.8 DEPLOYMENT DIAGRAM..........................................................61

4.9 ENTITY RELATIONSHIP DIAGRAM...............................................62

5.IMPLEMENTATION.........................................................................65

6.SOFTWARE TESTING....................................................................68

7.CONCLUSION AND FUTURE WORK...............................................126

UIIT, PMAS, UAAR, 2011 Page viii


BIBLIOGRAPHY................................................................................128

APPENDIX A USER GUIDE................................................................130

UIIT, PMAS, UAAR, 2011 Page ix


Chapter 1

INTRODUCTION

1.1 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.1User Registration

Users have to register before buying, selling, placing ads,

placing bids and taking part in discussion forum through user

registration form.

1.1.2Selling & 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.3Sending 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.4Vehicle 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.5User 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.6Discussion 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.7Advertisements

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.



Fig 1.1 System architecture

1.5 PROPOSED SYSTEM COMPONENTS

Our proposed solution has following components


User (Admin, Seller, Buyer, Mechanic)

POP3, SMTP and HTTP

HTTP

Web Browser

User PC

Windows OS

IIS

Server (Mainframe)

Web Server

WindowsServer

SMS Gateway

SQLdatabase

MicrosoftSQL server

2005

Database Server

ADO. Net

mobile

EmailServer

GSM


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


BuyerBuyer SellerSeller

Cell PhoneCell PhoneCell PhoneCell Phone


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.

1.6 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

Manager

It will help the Project Manager to manage the

overall activities of project.

DevelopersIt will help the developers to develop the system

according to the specifications or requirements.

Testers

Testers will test the system according to the

specifications and requirements mentioned in this

document.

Marketing

Managers

It will help Marketing manager to advertise the

product.

Document

Writer

It will help document writer to write detailed

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/

texttospeechproductsforpocketpc.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/


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


http://www.carfax.com/


http://www.carcitysupercenter.com/

http://www.smartmuseum.eu/del/D3.1b_SM.pdf


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


BuyerBuyer SellerSeller

Cell PhoneCell PhoneCell PhoneCell Phone


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 SpecificationsServer 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 RequirementsAbove 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

i. Reliability

No interruption should be occurring wile sharing

information with each other.

ii. Flexibility

Any module should be enhanced and added.

iii. Performance & Ease of use

The Software will user friendly and enhance performance while

conducting Risk Assessment.

iv. 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.



v. 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.

vi. Portability

The system can run on all kinds of mobile phones.

Other Requirements

vii. 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

4.1.1 Use case Model


Admin

Mechanic

Visitor

Buyer

Register

Seller

Place Bid

PlaceAdvertisement

Manage Bid Manage Ads

Post Add

Send Bid info

Make Payment

Send SMS SendE-mail

RemoveAddSearch Vehicle

<<extends>>

View OverallHistory

View BidHistory

View vehicleHistory

Buy Vehicle

<<extends>>

Verify card

DeleteMessages

Manage Forum

Finalize Bids

Pay Bid Fee

<<includes>>

Authentication

ForumFeedback

CommentsVehicle

Condition

<<extends>>

SystemGenerated

(automatic)

SearchVehicle

Mechanic

Refundableif bid fails

<<extends>>

SystemGenerated

(automatic)

Sale Vehicle

SendE-mail

Send SMS

if desiredvehicle not

found

Put Request

InformBuyer

UploadVehicle Info

if any buyeris waiting

<<extends>>

InformBuyer

View Vehicleinfo

RateMechanic

<<extends>>

SearchCriteria

<<include>>


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

(Unregistered )Visitor

Stake holder and their

interest

Casual users: Want to search the vehicle of

their choice

Precondition Internet connection

Success guaranteeThe user will be able to search the required

information

Main success scenarioThe system will provide fast and efficient

searching

Extension

1. User can be registered to sale,

purchase, place advertisement etc

2. User can place bid

3. User can view bid history

Special requirementUser should have basic knowledge of using

internet (browsing)

Technology and data

variation listInternet connection , HTML,ASP

Frequency of

occurrenceWhenever any user want to visit the site

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


interest

Casual users: Want to register to become a

regular user

Precondition The user will make a Request for registration

Success guaranteeThe user will registered to access full

functionality

Main success scenarioThe user will registered to access

functionality

Extension

1. After registration user will be informed

by SMS/ Email about user name &

password

2. User will be informed by SMS/ Email

about vehicle sale, purchase, bidding etc

Special requirementUser should have basic knowledge of using

internet (browsing)

Technology and data


Frequency of

occurrenceWhenever user request for registration

Table: 4.2.2 User Registration (All Users/Visitors)



Use Case section Comments

Use Case name Visitor Registration


Level Sub Function



interestCasual users: Want to register to become a regular user

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

Extension

1. After registration user will be informed by SMS/

Email about user name & password

2. User will be informed by SMS/ Email about

vehicle sale, purchase, bidding etc

Special requirementUser should have basic knowledge of using internet

(browsing)

Technology and data


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


Stake holder and their interestAll users: Registered as well as unregistered

Interest : To view overall history including

PreconditionUser may want to place a bid, advertisement, buy or sale

vehicle

Success guarantee The user will registered to access full functionality

Main success scenario 1. The user will registered to place bid

Extension

1. After registration user will be informed by SMS/

Email about user name & password

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

Frequency of occurrenceWhenever any user want to view the history or when the

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

Stake holder and their interest

Administrator: To manage Advertisements

Interest : To place new advertisements and to remove

old advertisement

PreconditionAdministrator’s Authentication or advertisement

placement

Success guaranteeAdministrator will manage Ads after registration &

authentication

Main success scenario

Managing Advertisements efficiently i.e.

Posting advertisements

Removing advertisements

Extension1. To place new advertisements

2. To remove old advertisement

Special requirement Administrator’s Registration & authentication

Technology and data variation listInternet connection , HTML,ASP

Ads may in image as well as video animation format

Frequency of occurrence

Whenever a new advertisement is to be placed

OR

Whenever an old advertisement is to removed

Table: 4.2.5 Manage Advertisements ( Administrator )




Use Case name Manage Bids


Level Sub Function



Administrator: The authorized personInterest : To manage bids

Precondition Administrator’s Authentication

Success guaranteeAdministrator will manage bids after registration & authentication


Managing bids i.e.

Finalizing bids and informing users

Bid announcement

Removing bids

Extension1. Finalize bids2. Send bid information (SMS / Email)

Special requirement Administrator’s Registration & authentication

Technology and data variation list

Internet connection , HTML,ASP

Frequency of occurrence

Whenever a new bid is to be placed

OR

Whenever an old bid is to removed

Table: 4.2.6 Manage Bids ( Administrator )




Use Case name Manage Forum


Level Sub function


Stake holder and their interestAdministrator: To manage forum

Interest : Remove unwanted messages & comments

Precondition Administrator’s Authentication

Success guaranteeAdministrator will manage forum after registration &

authentication


When users have to place comments and

messages log in is required

It requires registration

Extension

1. Check the comments on the forum and remove

unwanted messages.

2. To provide feedback about fake users and bids

Special requirement Administrator’s Authentication

Technology and data variation

listInternet connection , HTML,ASP

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

Interest : To check the vehicle’s condition and to

comment

PreconditionAuthorized person

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

comments about condition.

Log in and place the comments

Extension1. Check vehicle’s condition

2. Comment about the vehicle and

Special requirement The registered & authorized person

Technology and data variation list Internet connection ,HTTP, HTML, ASP

Frequency of occurrenceWhen sellers want comments or mechanic want to

inspect vehicle

Table: 4.2.8 Vehicle Inspections (Authorized Mechanic)




Use case name Sale Vehicle


Level User goal

Primary actor Seller


interest

Sellers: The registered users

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

Extension

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

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

variation listInternet connection , HTTP, HTML, ASP and GSM

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

Stake holder and their interestBuyers: 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

3. Sellers will give rating to mechanic of their choice


send to seller

Extension

1. When online user select buy vehicle option

2. The system will prompt show Vehicle info

3. Mechanic’s comments increases reliability and chances

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

Stake holder and their interestRegistered 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

Main success scenario1. User will log in

2. User will put comments and feedback

Extension

1. User may help each other to identify fake users.

2. User may inform each other about vehicle industry

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

Stake holder and their interestBuyer : 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

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

2. User will place advertisements

3. User will make payment

Extension1. User will place advertisements to sale vehicle

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

PreconditionAll registered users required authentication and bid registration fee

that is refundable if the bid fails

Success guarantee All registered users can place bids


1. Users will log in

2. Users will place bids

3. Users will pay bid fee that is refundable

Extension User may help each other to identify fake bids



Frequency of occurrence Whenever user want to place bids

Table: 4.2.14 Place Bids (For Registered Users)

4.3 Activity Diagram


Home Page

Authentication Registration

[Registered users] [Visitors]

[Invalid][Invalid]

[Valid] [Valid]

[Check Parameters][Check Parameters]

[Admin] [seller] [Buyer] [Mechanic]

Manage Ads Manage Bids

FinalizeBids

Send Bid Info(SMS/Email)

Sale Vehicle

Upload VehicleInformation

Buy Vehicle

AdvertiseVehicle Bid Vehicle

SaleNormally

Pay ForAdvertisement

inform User(SMS/ Email)

Browse choice(Vehicle)

View VehicleInfo

PutRequest

Comment VehicleCondition

Change Ads

Feedback

SearchMechanic


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.1Searching Vehicle



Fig: 4.5.1 Sequence of Sequence of Searching Vehicle

4.5.2User Registration


search_request

page_rendered

search:page

get_search_page

Buyer

vehicle_not_found

<< UI >>Browser

Database

view_vehicle_info

get_vehicle_info

return_vehicle_infoinfo_rendered


Fig: 4.5.2 Sequence of User Registration

4.5.3View Vehicle History


Reg_request()

Return_form

submit()

<< UI >>Browser

visitor

check _parameters() add_user()

Databaseregistration:

page

invalid _parameters

user_added()

user:thevisitor

get_reg_form

user_registered


Fig: 4.5.3 Sequence of View Bidding History

4.5.4Admin Log In (Admin has super rights)


search_request(url)

page _rendered

search:page

get_search_page()

User<< UI >>Browser

Database

view_bidding_history() get_bidding_details()

return_biding_detailshistory_rendered


Fig: 4.5.4 Sequence of Admin Log In

4.5.5Managing Advertisements


login_request

Return_form

submit

<< UI >>Browser

check _parametersmatch_password

<< UI >>Login_page

invalid _parameters

AuthorizedUser user:theuser

password_matchedlogged_in

password_not_matched

Database


Fig: 4.5.5 Sequence of Managing Advertisements

4.5.6Managing Bids


manage_ads

page _rendered

ads:adspage

get_ads_page

<< UI >>Browser

post_ads

Database

save_ads_info

saved_ads_infoads_posted

Administrator

remove_ads

ads_removed


Fig: 4.5.6 Sequence of Managing Bids

4.5.7Managing Forums


manage_bids

page _rendered

bids:page

get_bids_page

<< UI >>Browser

finalize_bid

Database

save_bid_info

bid_info_savedbid_ends

Administrator

remove_biddelete_bid_info

send _SMS/Email

user:the buyer

delete_bid_info bid_removed

inform_seller & buyer

SMS/Email_sentinformed_seller & buyer


Fig: 4.5.7 Sequence of Managing Forums

4.5.8User Feedbacks


manage_forum

page _rendered

forum:page

get_forum_page

<< UI >>Browser

post_message

Database

save_message

message_savedmessage_posted

Administrator

remove_message

message_removed

delete_message

message_deleted


Fig: 4.5.8 Sequence of User Feedback

4.5.9Vehicle Inspection (Mechanic’s Module)


feedback_request

page _rendered

forum:page

get_feedback_page

<< UI >>Browser

post_message

Database

save_message

message_savedmessage_posted

Registered user

remove_message

message_removed

delete_message

message_deleted


Fig: 4.5.9 Sequence of Vehicle Inspection

4.5.10 Selling Vehicle


vehicle_comments

page_rendered

search:page

get_comments_page

Buyer<< UI >>Browser

Database

post_comments save_comments

comments_saved posted_comments


Fig: 4.5.10 Sequence of Selling Vehicle

4.5.11 Buying Vehicle


sale_vehicle

page _rendered

vehicle_info:page

get_sale_page

Seller<< UI >>Browser

user:the buyer

upload_vehicle_info

search_mechanic

inform_buyer (SMS/Email)

Database

save_vehicle_info

vehicle_info_saved

SystemGenerated

(automatic)

user:the mechanic

get_mechanic_info

return_mechanic_infomechanic_info_rendered


Fig: 4.5.11 Sequence of Buying Vehicle

4.5.12 Put Buy Request


buy_vehicle

page _rendered

vehicle_info:page

search_vehicle

Buyer<< UI >>Browser user:the seller

view_vehicle_info

rate_mechanic

inform_seller (SMS/Email)

Database

get_vehicle_info

vehicle_info_returned

SystemGenerated

(automatic)

vehicle:the vehicle

check_parameters

store_mechanic_rating

rating_assigned


Fig: 4.5.12 Sequence of Put Buy Request

4.5.13 Placing Bid


search_vehicle

page_rendered

search:page

get_search_page

Buyer<< UI >>Browser

Database

put_request save_request

request_saved posted_vehicle_request


Fig: 4.5.13 Sequence of Placing Bids

4.5.14 Placing Advertisements


bid_request

page _rendered

bids:bidspage

get_bids_page

User<< UI >>Browser payment:pay

place_bid make_payment

Database

save_bid_info

saved_bid_infopayment_verifiedbid_placed

Refundableif bid fails


Fig: 4.5.14 Sequence of Placing Advertisements

4.6 Class Diagram


advertisement_request

page _rendered

ads:adspage

get_ads_page

User<< UI >>Browser payment:pay

place_ads make_payment

Database

save_ads_info

saved_ads_infopayment_verifiedads_placed


Fig. 4.6.1 System Class Diagram


User

- ID : int- Email : String- LoginStatus : String

+ varifyLogin() : bool+ search()+ viewProfile()+ feedback()

Visitor

- ID : int- Name : String

+ search_vehicle()+ ViewHistory()

Seller/Buyer

- Name- Password : String- PhoneNo : int- CreditcardInfo :String

+ register()+ login()+ add_profile()+ update_Profile()+ buy()+ sale()+ bid()

Mechanic

- Name : String- Password : String- PhoneNo : int- Location : string- Charges : int

+ login()+ checkVehicle()+ comments()

Bid

- BidID : int- BidAmount : int- OwnerID : int- Date : Date- Time : Date/Time- BestBid : int

+ place_bid()+ view_bid()+ start_bid()+ cancel_bid()+ finalize_bid()+ close_bid()+ makePayment()

All Classes haveCRUD operations

likeInsert,Update,

Delete etc<<extends>>

search

check

sell/buy

1

11

0..*

1..*

*

*

*

*

Forum

- Subject : String- Postedby : String- PostedDate : Date

+ forum_feedback()+ post_Comment()+ del_Comment()

Admin

- adminName : String- Password : String

+ login()+ manageBid()+ manageForum()+ manageProfile()+ manageVehicle()

Vehicle

- Vehicle_ID : int- Image- Model : String- EngineNo : int- ChassisNo : int- Registration : String- Color : String- Price : int

+ search()+ vehicle_Info()+ advertise()+ view()+ mechanic_comment()

1..*

View

man

ag

e

0..*

manage

1..*

1..*

1..*

1..*

* 1..*

History

- History(Sale)- History(Purchase)- History(Bid)

+ View_History()+ Vehicle_history()+ bid_history()

*

manage

1..*

0..*

1

1

Advertisement

- Ad_ID : int- Posted_date : Date

+ place_add()+ post_add()+ remove_add()

1..* *Place


4.7 Entity Relationship Diagram

Fig. 4.7.1 System RE Diagram



4.8 Deployment Diagram

Fig. 4.8.1 System Deployment Diagram

4.9 Operational Contracts


User (Admin, Seller, Buyer, Mechanic)

POP3, SMTP and HTTP

HTTP

Web Browser

User PC

Windows OS

IIS

Server (Mainframe)

Web Server

WindowsServer

SMS Gateway

SQLdatabase

MicrosoftSQL server

2005

Database Server

ADO. Net

mobile

EmailServer

GSM


4.9.1 User Registration

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.1Presentation 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.2Business 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.3Data 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.

6.1.2TEST 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 QasimTest Type Unit TestingTest Case Number OVS0001Test 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

2All the required fields(Email, Address, Username, Password, Phone number, CNIC No, Province, City)

Specifications

InputExpected

Output/Result1)Click on registration link2) Enter all required fields with correct values and then click on register button.

1)The registration page will be opened 2)user will successfully registered and values will be stored in database

Procedural Steps

1 User will click on registration link .the registration page will open.

2 Enter the required values with correct data values.

3 Click on register

4If already user is not registered than successfully it will registered and message will be displayed.

Table 6.7.1: Test case of User Registration



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0002Test Case Name Test Login

Test Case Description

In this test case the email address and password 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

InputExpected

Output/ResultUser name and password of the registered user .

Login will be successful and account will be accepted.

Procedural Steps

1 User will enter his correct User name.

2 User will enter his password

3 Click on login

4If registered than successfully access his account otherwise error will be displayed

Table 6.7.2: Test case of login



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0003Test Case Name Test Validation


In this test case tests the validations applied on 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.

2Validate the fields against numbers, empty field or special characters e.g. ~!@#$%^&*()_:";'{} .

Specifications

InputExpected

Output/ResultEntry in text fields. Values are successfully inserted in

record.

Procedural Steps

1 User opens the required form to fill.

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.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0004Test 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.

2Account is successfully updated or not.

Specifications

InputExpected

Output/Result(1)Enter previous password.

(2)Enter security question and answer.

Account is successfully updated and record is successfully inserted in database.

Procedural Steps

1 User will open account updating form.

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.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0005Test Case Name Test Advertise Vehicle


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.


1 Insertion of record of selling vehicle.

2 Validate all the fields.

Specifications

InputExpected

Output/Result(1)Click to sale vehicle from menu.

(2)Enter correct values in all the fields of form and click on Save button.

Account is successfully updated.

Record is inserted in database.

Procedural Steps

1 User will click on sale link.

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.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0006Test 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

InputExpected

Output/ResultType specifications of desired vehicle.

Search is successful.

Procedural Steps

1 User will click on search link.

2 Enter correct specification of desired vehicle.

3 Click on Search button.

Table 6.7.6: Test case Search Vehicle.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0007Test 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

InputExpected

Output/Result(1)Click to Vehicle Inspection link.

(2)Enter correct comments about vehicle after inspecting the particular vehicle.

Comments of mechanic successfully inserted in database of particular vehicle.

Procedural Steps

1 Mechanic will click inspection link.

2 Check the vehicle.

3 Enter correct inspection detail about vehicle.


Table 6.7.7: Test case Vehicle Inspection.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0008Test 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

InputExpected

Output/Result(1)Click to place bid link.

(2)Enter Vehicle details.

(3)Time and date of expiring bid.

Vehicle profile is updated and bid is placed successfully.

Procedural Steps

1 User will click on place bid link from menu.

2 Enter detail of vehicle.

3 Enter bidding price.


Table 6.7.8: Test Case Place Bid.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0009Test Case Name Test Bidding Price


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.


1 Vehicle to place a bid.

2 Check last entered bid price.

3 Bid is finalized or not.

Specifications

InputExpected

Output/Result(1)Select bidding vehicle.

(2)Enter correct bid price.

(3)Finalize bid.

Bid price is entered correctly.

Procedural Steps

1 User will click on available bids link from menu.

2 Enter price of bid.


Table 6.7.9: Test Case Bidding Price.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0010Test Case Name Test Finalize Bid


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.


1 Vehicle to place a bid.

2 Check last entered bid price.


4 Check expiring date and time of bidding.

Specifications

InputExpected

Output/Result(1)Select bidding vehicle.


(3)Finalize bid.

Bid price is entered correctly and bid is finalized successfully and user. Congratulation message will be displayed.

Procedural Steps

1 User will click on available bids link from menu.

2 Enter price of bid.

3 Finalize the bid.

4 Contact to the seller.


Table 6.7.10: Test Case Finalize Bid



Tested By: Muhammad QasimTest Type Unit TestingTest Case Number OVS0011Test 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

InputExpected

Output/Result(1)Select Vehicle to buy or the bidding vehicle.


(3)Finalize bid.

Confirmation message will be displayed and both the users will be informed instantly.

Procedural Steps

1 User will click on vehicle available to purchase.

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.



Tested By: Muhammad QasimTest Type Unit TestingTest Case Number OVS0012Test 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

InputExpected

Output/ResultConfirm the user to send email. Email is successfully generated

from System.

Procedural Steps

1 User will perform the sale or purchase activity.

2 Confirm that activity.


Table 6.7.12: Test Case Mail Server.



Tested By: Muhammad QasimTest Type Unit TestingTest Case Number OVS0013Test 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

InputExpected

Output/ResultConfirm the user to send email.Arrival of Email.

Email is successfully sent from the System to appropriate user to inform.

Procedural Steps

1 User will perform the sale or purchase activity.

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.



Tested By: Muhammad QasimTest Type Unit TestingTest Case Number OVS0014Test 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

InputExpected

Output/ResultSMS is sending by the connected GSM device.

SMS is successfully sent.

Procedural Steps

1 GSM will send the SMS

2 SMS will send to the relevant person.

Table 6.7.14: Test Case Send SMS.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0015Test Case Name Test Create Forum Topic


This test will verify that whether the Topic of 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

InputExpected

Output/ResultUser will post the discussion topic. Topic is successfully posted on the

discussion forum.

Procedural Steps

1 User will Select the Forum link from menu.

2 Create title of Topic.


Table 6.7.15: Test Case Create Forum Topic.



Tested By: Muhammad ShafiqTest Type Unit TestingTest Case Number OVS0016Test 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

InputExpected

Output/ResultUser will place the advertisement. Advertisement is successfully

placed.

Procedural Steps

1 User will Select the Place Advertisement link from menu.

2 Place advertisement title.

3 Select images for advertisement.


Table 6.7.16: Test Case Place Advertisement.



Tested By: Muhammad Shafiq Test Type Unit TestingTest Case Number SV0017Test 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

InputExpected

Output/ResultClick on logout button Users will logout successfully and

session will be expired.

Procedural Steps

1 User will click on logout button

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 executionSoftware: Online Vehicle ShowroomModulation:User RegistrationTest Name: Test Registration Test ID: OVS0001Test 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

required field try to

enter a record except

email address

Prompt that

enter email

address

Prompt that

enter email

address

OVS0001 Username field is a

required field try to

enter all fields except

Username

Prompt that

enter your

Username.

Prompt that

enter your

Username

OVS0001 Try to enter string

values in Phone

number field

Prompt that

enter your

integer values

Prompt that

enter your

integer values

OVS0001 Minimum limit of

password length is 8

try to enter less than

8 digits

Prompt that

enter minimum

8 character in

length

Prompt that

enter minimum

8 character in

length

OVS0001 Verify that address

field is required field

by keeping this field

empty.

Prompt that

enter address it

is required.

Prompt that

enter address it

is required.

OVS0001 Enter all fields except

the CNIC No and click

on submit

Prompt that

select CNIC No

from given it is

required

Prompt that

select CNIC No

from given it is

required

OVS0001 All field values are

correct

Prompt you are

registered

Prompt you are

Register

Software: Online Vehicle Showroom

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.

Test Case ID Test Input Expected

Result

Actual Result

OVS0002 Enter your Username

in username field and

click login

The Username

will be accepted

The Username

will be accepted

OVS0002 Enter only password

keep the Username

field empty and click

login

Prompt that

enter your

Username

Prompt that

enter your

Username

OVS0002 Enter only Username

and keep the

password field empty.

and click login

Prompt that

enter your

password

Prompt that

enter your

password

OVS0002 Enter wrong password

and click login

Prompt that

password is

wrong

Prompt that

password is

wrong

OVS0002 Enter wrong

Username and click

login

Prompt that

user is not

registered.

Prompt that

user is not

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

Actual Result

OVS0003 Enter numeric valued

into any text field

and click login

Prompt that

enter correct

value in text

field

Prompt that

enter correct

value in text

field

OVS0003 Enter only password

keep the Username

field empty and click

login

Prompt that

enter your

Username

Prompt that

enter your

Username

OVS0003 Enter only CNIC No in

text field with string

Prompt that the

format entered

CNIC No is wrong

Prompt that the

format entered

CNIC No is

wrong

OVS0003 Enter wrong

password and click

login

Prompt that

password is

wrong

Prompt that

password is

wrong

OVS0003 Remains empty any

text field and click

login

Prompt that text

field cannot be

blank.

Prompt that text

field cannot be

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

empty in password

recovery

Prompt that the

Username must

enter

Prompt that the

Username must

enter

OVS0004 Value of Security

Question and Answer

fields are not chosen.

Prompt that the

security question

and answer must

be given to

update your

account

Prompt that the

security

question and

answer must be

given to update

your account

OVS0004 Keep Price field

empty and click on

Save button

Prompt that enter

the price of

vehicle

Prompt that

enter the price

of vehicle

OVS0004 Enter price in price

field with string value

Prompt that the

string value does

not accepted

Prompt that the

string value

does not

accepted

OVS0004 Click Save button

with all empty fields

of the form

Prompt that all

the fields must be

fill.

Prompt that all

the fields must

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

Actual Result

OVS0005 Not selected any

value from dropdown

list and click Save.

Prompt that

select values

from dropdown

list

Prompt that

select values

from dropdown

list

OVS0005 Enter value of

Mileage field in string

Prompt that

enter numeric

value for

mileage

Prompt that

enter numeric

value for

mileage

OVS0005 Keep Price field

empty and click on

Save button

Prompt that

enter the price

of vehicle

Prompt that

enter the price

of vehicle

OVS0005 Enter price in price

field with string value

Prompt that the

string value does

not accepted

Prompt that the

string value

does not

accepted

OVS0005 Click Save button

with all empty fields

of the form

Prompt that all

the fields must

be fill.

Prompt that all

the fields must

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

Actual Result

OVS0006 Keep empty search

textbox

Prompt that no

item is selected

Prompt that no

item is selected

OVS0006 Enter special

characters in text

field

Prompt that no

item is match

Prompt that no

item is match

OVS0006 No connectivity to

database

Prompt that no

item is found

Prompt that no

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

Actual Result

OVS0007 Keep empty field of

General Condition of

vehicle

Prompt that

condition must

be selected

Prompt that

condition must

be selected

OVS0007 Click on Save button

without selecting

engine condition

Prompt that

Engine Condition

is not selected

Prompt that

Engine

Condition is not

selected

OVS0007 Keep the field empty

of Mileage textbox

Prompt that

enter the value

of mileage

Prompt that

enter the value

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

Actual Result


Price of vehicle

Prompt that

Enter the price

of bid

Prompt that

Enter the price

of bid


without selecting any

field

Prompt that all

the fields must

be selected

Prompt that all

the fields must

be selected

OVS0008 Enter value of price

in string

Prompt that

price in string

cannot be

accepted

Prompt that

price in string

cannot be

accepted

OVS0008 Enter numeric value

in Color textbox

Prompt that

enter correct

color of vehicle

Prompt that

enter correct

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

Actual Result


Bidding Price of

vehicle

Prompt that

Must enter the

price

Prompt that

Must enter the

price

OVS0009 Enter price less than

price of last bid

Prompt that

price must be

greater than last

bid placed

Prompt that all

the fields must

be selected


in string

Prompt that

price in string

cannot be

accepted

Prompt that

price in string

cannot be

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

Actual Result


Bidding Price of

vehicle

Prompt that

Must enter the

price

Prompt that

Must enter the

price

OVS0010 Enter price less than

price of last bid

Prompt that

price must be

greater than last

bid placed

Prompt that all

the fields must

be selected


in string

Prompt that

price in string

cannot be

accepted

Prompt that

price in string

cannot be

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

Actual Result

OVS0011 Keep empty fields of

form of vehicle

bidding

Prompt that all

fields must be

filled

Prompt that all

fields must be

filled

OVS0011 Close without click on

Save button

Prompt that

bidding is not

finalized

Prompt that

bidding is not

finalized

OVS0011 All fields are entered

correctly and click on

Save button

Configuration

will be saved

Bidding saved and finalized successfully.


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

Actual Result

OVS0012 Email Server

Connection

Prompt that

Server is not

found

Prompt that

Server is not

found

OVS0012 Keep some fields

empty and click on

save

Prompt that all

fields must be

filled

Prompt that all

fields must be

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

Actual Result

OVS0013 Arrival of an Email Email will sent to

the user

successfully

Email will sent

to the user

successfully

OVS0013 Keep some fields

empty and click on

save

Prompt that all

fields must be

filled

Prompt that all

fields must be

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

Actual Result

OVS0014 Select all values from

dropdown lists and

click on connect

button

New

configuration of

GSM will be

saved

New

configuration of

GSM will be

saved

OVS0014 Select all values

except COM port

Prompt that

selects COM

port.

Prompt that

selects COM

port.

OVS0014 Click on Connect Configuration

will successfully

make.

Configuration

successfully

saved.

OVS0014 Click on Disconnect All newly made

changes will

discard

All newly made

changes discard

OVS0014 Click on Send Button SMS will be sent

successfully

SMS will be sent

successfully


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

Actual Result

OVS0015 Type title of Forum in

numeric value

Prompt that the

Forum topic

must be in string

Prompt that the

Forum topic

must be in

string

OVS0015 Click on Post button

without giving title

name of forum

Prompt that

Topic Title must

be entered

Prompt that

Topic Title must

be entered

OVS0015 Click on Post button Forum topic is

posted

successfully

Forum topic is

posted

successfully


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

Actual Result

OVS0016 Click on

Advertisement

without login

Prompt that you

must login

before place an

advertisement.

Prompt that you

must login

before place an

advertisement.


without title

Prompt that title

must be entered

Prompt that title

must be entered


with numeric value in

title text field

Prompt that the

numeric value

cannot be

accepted

Prompt that the

numeric value

cannot be

accepted

OVS0016 No images selected

for advertisement

Prompt that click

on Browse

button to select

images

Images are

selected for

advertesement


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 ResultOVS0017 User will click on

Logout Button

Session will Expire

and user will

successfully logout

and logout link

Button will be

invisible.

Session Expires

and user

successfully

logout and

logout link

Button become

invisible.

OVS0017 User will click on

any other Link

Button instead of

logout

The user will not be

logged out

The user not

logged out.

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 1 st 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 1 st 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 1 st

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


Documents

Final Project Documentation