SellSmart Project Proposal



CS551 Advanced Software Engineering

SellSmart©

Project Proposal

September 27, 2003

by

DesiGeeks

Vinit Nagda (vmn5xc@umkc.edu)

Deepa Colluru (dczn6@umkc.edu)

Uday Kapoor (uk5w9@umkc.edu)

Venetia Raheja (vsrxtd@umkc.edu)

Sampath Akkineni (skaty8@umkc.edu)

Vijay Bhaskar Puram (vbprh7@umkc.edu)

Wenxuan Kang (wkq49@umkc.edu)

School of Computing & Engineering

University of Missouri Kansas City

Table Of Contents

1 Introduction 4

1.1 Purpose of this document 4

1.2 Scope of this document 4

1.3 Brief Overview 4

1.4 Business Context 4

2 Project Goal and Objectives 5

2.1 Overall Goal 5

2.2 Specific Objective 5

2.3 Significance 6

3 PROJECT BACKGROUND 7

3.1 Work Done By Others (Critiques) 7

3.1.1 Component Technologies: Java Beans, COM, CORBA, RMI, EJB and the CORBA Component Model 7

3.1.2 Mobile Computing in the retail Arena 7

3.1.3 Designing Interfaces for Handheld Computers 7

3.1.4 Java Native Interface: Technology Programming 8

3.1.5 Use of a CORBA/RMI Gateway: Characterization of Communication Overhead 8

3.1.6 Web Services: An Architectural Overview 8

3.1.7 A Detailed Comparison of CORBA, DCOM and Java/RMI 9

3.1.8 PDA Car Lot [2] 9

3.1.9 Car Buyer Calculator 1.0 9

3.1.10 Pocket Verifier- Windows CE 3.12 10

3.1.11 Starcloser 10

3.1.12 Stronghold 10

3.1.13 CarSmart 10

4 General plan OF WORK 11

4.1 Proposed Solution 11

4.2 Methods & Procedures 11

4.2.1 Display() 11

4.2.2 Login/Authentication 11

4.2.3 Browse inventory 11

4.2.4 Search the inventory 11

4.2.5 Find Availability 11

4.2.6 DbConnect() 11

4.2.7 InitSQL() 12

4.2.8 ProcessResults() 12

5 Proposed System 13

5.1 Domain Analysis 13

5.2 Requirements 13

5.2.1 Display Welcome Screen 13

5.2.2 Registration and Authentication 13

5.2.3 Search Screen 13

5.2.4 Search Results Screen 13

5.2.5 Favorites List 13

5.2.6 Sales Agents Reqs 13

5.2.7 Information From Other Dealers 13

5.2.8 Concurrent use 14

5.2.9 Portability 14

5.2.10 Reliability/Accuracy 14

5.2.11 Performance/SLA 14

5.3 Business Model 14

5.4 Stakeholders 14

5.5 Proposed System Architecture 15

6 Timetable 16

7 Bibilography 17

Introduction

1 Purpose of this document

This document is intended for the use by the business analysts to examine basic functionality and also provides a brief overview of the product details. The document compares the product “SellSmart” with similar products available in the market and provides a comparison between them. The document describes the objective behind developing the product. The plan of work that would comprise of descriptions of the methods and procedures along with the expected results is also provided. The document analyses the requirements, business model and interest of the stakeholders.

2 Scope of this document

The document provides detailed requirements, which would be used to develop the product. The developers would analyze the requirements and bring to the knowledge of the project requestor any conflicting requirements that cannot be met.

3 Brief Overview

SellSmart is a software system that provides the car dealers and customers the benefits of a handheld device to access car details while shopping at the car lot. Customers could browse through the online information database and search for the cars they have in mind by using various search criteria such as the Make, Model and Price etc. Car salesmen, on the other hand have access to the above-mentioned data as well as critical and confidential information. The system also provides the customer and salesman the ability to search for a car beyond the confines of the dealership.

4 Business Context

SellSmart would aid in the sales effort of the dealership to maximize sales while reducing the required manpower. Millions of car shoppers do not buy cars online because automakers are misfiring with their marketing efforts [1]. SellSmart offers the customers to search the dealers inventory using many offered search criteria with the added advantage of viewing, test driving, comparing various available options in the car lot.

Project Goal and Objectives

1 Overall Goal

The overall purpose of SellSmart is to redefine car sales by automating the entire process beginning from selection to negotiation and ending in a successful deal. SellSmart enhances the customer car shopping experience by keeping a constant focus on the customer’s requirements and satisfaction. Highlights of SellSmart are:

➢ Customers can search for the car they have in mind using various criteria and start their short-listing process by viewing the exact cars and what they have to offer as specified by the search results.

➢ Sales representatives would not require subsequent trips to their office to fetch details pertaining to each customer query.

➢ Customers can maintain a profile in which they could shortlist cars they are interested in.

➢ Sales people could take additional notes regarding a prospective customers contact information which will come in handy during follow up sales calls.

➢ SellSmart helps save customers their precious time by avoiding to wait for a sales representative to help them, instead they could help themselves using the PDA client application.

➢ The dealership could guarantee customer satisfaction by diverting their queries to partner dealerships if the customer requests cannot be satisfied by them.

2 Specific Objective

The dealership would like to be a channel partner and become point of contact to sell cars available in the partner’s car lot. A major challenge to be overcome is to bridge the gap between various technologies used by different partner dealerships and provide a single point of access to the end consumer. To overcome the above-mentioned obstacle, SellSmart proposes the development of an “Adaptation Layer” which communicates with various technologies at the backend and presents the front end with a consistent user interface.

The dealership does not intend to limit its partnerships to select few dealerships but instead requires that the solution be flexible and scalable to add and remove partner links as required. One of the ways the requirement can be satisfied is to provide a web-service to provide a unified method to access information available in their own database along with information obtained via the adaptation layer. SellSmart would provide such a web-service to access information from the PDA client application. The utilization of the web-service could be increased by developing a web portal to access the same information using a web browser. The mentioned web portal is beyond the scope of this project and could be considered as a future enhancement.

One of the requirements of the dealership is to make its work force mobile and increase their productivity by servicing the customers better and provide instantaneous answers to their queries. To meet the requirements of a mobile client application, SellSmart would develop a PDA client using Microsoft Mobile .Net framework. The requirement could be met by making the client application as thin as possible, restricting it to be used as an interface to receive customer input and display result. In this architecture the web-service would be used as a medium to provide bi-directional communication between the client application and the server application, which will be doing the bulk of the processing.

3 Significance

SellSmart would change the way people buy cars and the way car dealerships do business. The project aims at taking the auto sales industry to the next level by promoting co-operation amongst various dealerships. Successful implementation of SellSmart would result in various partnership agreements amongst competing dealerships and benefit the customer by providing a vast collaborated inventory to choose from. SellSmart implements the adaptation layer which bridges the gap between various technologies making it easier for dealerships to collaborate on sales efforts and maintaining their own infrastructure and individual identity at the same time.

PROJECT BACKGROUND

1 Work Done By Others (Critiques)

In this section, we present an analysis of our research on products parallel to SellSmart. (Our Competitors!!!)

1 Component Technologies: Java Beans, COM, CORBA, RMI, EJB and the CORBA Component Model

This paper describes the evolution of object oriented programming into local component models such as Java Beans and distributed object technologies such as CORBA, RMI and COM. Existing component-based and distributed technologies are classified into three categories, local component technology, distributed object technology and distributed component technology. In local component technology, all components reside on the same host at execution time. Examples of the local component technologies are Sun’s Java Beans and Microsoft’s COM. Bean components communicate by sending events to one another using a publish/subscribe model. In distributed object technology, communication between objects occurs by method invocations. Application developers do not have to deal with complexities such as location of objects and heterogeneous hardware/software platforms. Middleware technologies also offer other services such as security, persistence, naming and trading. Distributed component models evolved from the deficiencies existed in different middleware technologies. These technologies combine the characteristics of components with the functionality of middleware systems to provide inter-process communication between components. Two distributed component models that are available now are Sun’s Enterprise Java Beans (EJB) and CORBA component model. These are server-side component models used for developing distributed business objects.

2 Mobile Computing in the retail Arena

With the rapid rate at which wireless technology is improving, more PDA’s and handheld computers are becoming a part of every day life. The authors at Georgia Institute of technology conducted a study on how the use of a PDA aids our grocery shopping. They observed the shopping habits of several people and designed an application that would help them grocery shop from the “shopping” perspective, leaving aside the shopping environment. A noteworthy observation was made that shoppers want more information, control and convenience. The designed application provided people with an option to create a shopping list. The in-store information system could even analyze the shopping habits of a customer and present a shopping list based on buying frequency. Special emphasis was maintained while designing the user interface, which was incorporated with the store map and provided shoppers with an icon, marking the location of items on the list. The prototype was developed for the MS Pocket PC platform. User comments about the applications formed a mixed bag, people familiar with PDA usage found the application made their shopping experience better. On the other hand, people not familiar with PDA usage and interface found the application limiting. More of such applications will become available as people become more familiar with PDA usage day by day.

3 Designing Interfaces for Handheld Computers

This paper discusses guidelines for designing effective Handheld Application Interfaces. It tries to explain the point that developers should not use desktop metaphors in their designs while designing a user interface for handhelds. It provides very good insights into designing screens and dialog boxes, designing for speed, employing benchmarks and also overall application design.

Despite similarities in functionality, or being made of the same components, desktop and handheld computers are different entities with different users and uses. The obvious reasons for a fresh design are absence of keyboard, use of finger or stylus, limited user screen, and many more. The author suggests careful placement of controls on screen, using progressive disclosure, large buttons over which stylus can be used, and consistency with platform of choice. Also considering factors like integration with desktop computer; design for speed, decreasing the overall navigation in application, and very less reliability on always being connected.

We found the article extremely useful, all of us being novice handheld application developers.

4 Java Native Interface: Technology Programming

Computer languages are created, reformed, and die at a rapid pace with the evolution of computer engineering. This cycle presents problems throughout any system’s life cycle as the system’s core technologies become dated and new technologies arise that could streamline operations. While the new technologies often provide benefits, these benefits rarely justify rewriting entire libraries of code. Another problem with this cycle is that in any given environment (office, lab, building, etc.), a number of systems may exist all written in different languages that reflected the height of technology at its birth. Integrating these systems then becomes a large chore.

The JNI presented here provides solutions to both of the above problems: by allowing access to any native language the JNI allows Java to access any legacy code library or system directly, cutting out the need to string objects between the two. It also allows for the consolidation of any number of differently programmed systems into one unified architecture because once JNI extracts the classes from the native language it can use the core Java principles of inheritance to cast these native objects to well defined Java objects.

We were facing a technical problem during designing the SellSmart system, how to call COM from Java. From this paper we got a solution, using JNI as the bridge to connect COM and Java code. Is it the only way to do this? Need more effort to know.

5 Use of a CORBA/RMI Gateway: Characterization of Communication Overhead

The paper discusses about the gateway module, which acts as a link between two different communication frameworks. The gateway passes service requests between different middle ware solutions. In this paper CORBA AND RMI are taken as the middle ware solutions. The problems involved and the counter measures that are to be taken for the improved performance are briefly explained.

Integration of number of service components in a web service system is based on keeping the same transport framework and adding to that number of service components. The gateway module described allows these service components on different frameworks to access each other. The problem involved is quick response which is measured by considering Round Trip Time and generating various graphs. Solution proposed to the above problem is aptly placing the gateway in the client side or server side. We can use this concept of integrating different communication frame works in the adapter layer of our project.

6 Web Services: An Architectural Overview

Web services represent an architectural structure that allows communication between applications. A service can be invoked remotely or be used to employ a new service together with other services. The standard technologies for web services are Web Service Description Language (WSDL), Simple Object Access Protocol (SOAP) and Universal Description, Discovery and Integration (UDDI). The choice of web services is made because it is platform independent. A web service component is described in service description language, published in a registry and discovered by a standard mechanism. Web services contain the best accomplishments of web-based component development. Web services contain black-box functionalities that can be reused without caring in what language it will be used in.

7 A Detailed Comparison of CORBA, DCOM and Java/RMI

Three of the most popular distributed object paradigms are Microsoft’s Distributed Component Object Model (DCOM), OMG’s Common Object Request Broker Architecture (CORBA) and Javasoft’s Remote Method Invocation (RMI). This article describes the three different technologies and provides a comparison from a programmer’s standpoint and an architectural standpoint.

The following are the similarities/differences between the three different technologies. DCOM supports multiple interfaces whereas CORBA and RMI support multiple inheritance at interface level. In DCOM, every object implements IUnknown, in CORBA every interface inherits from CORBA.Object and in RMI every server object implements java.rmi.Remote, java.rmi.UnicastRemoteObject. DCOM uniquely identifies a remote server object through its interface pointer, CORBA identifies remote server objects through object references and RMI identifies remote server objects using object id. DCOM uniquely identifies an interface using interface ids and uniquely identifies a named implementation of the server object using class ids. Interface id and class id mapping is found in the registry. CORBA identifies interface using interface name and identifies a named implementation of server object by mapping in the implementation repository. RMI identifies interface using interface name and identifies named implementation of server object by its mapping to a URL in the registry. In DCOM, the object exporter performs remote server object reference generation. CORBA performs remote server object reference generation with the object adapter. In RMI, remote server object reference generation is performed by the call to the method UnicastRemoteObject.exportObject(this). Author has done a great job by providing a detail description of the similarities and differences that are beyond the scope of this project proposal.

8 PDA Car Lot [2]

The PDA Car Lot tool developed by Palmtree.ca assists auto sales. The program has customizable drop lists for fields such as vehicle make, model color and others. The database can be filtered to show data specified. Many filter/search capabilities are available. It will keep track of the inventory and will also log your potential clients and their information. The product does not give the location of cars and only gives the details of the car available with the dealer and does not fetch information from the web. Moreover it is a tool for salespersons, not for the customers.

9 Car Buyer Calculator 1.0

Car Buyer Calculator tools assists when buying a new or used car. When buying a car, it is difficult to consider and compare your cost description of all cars. This calculator can help calculate the total cost that the user/customer pays and saves, and it helps compare the total cost of one car model with the total cost of the others car buying model. The parameters that are handled are: Depreciation Cost, Finance Cost, Insurance, Cost, Fuel Cost, Maintenance Cost, Total cost of buying and owning, Annual cost to own and operate Cost per mile. This tool only helps with the cost aspect. Other visual and technical features are ignored. The technology inside the car and luxury facilities is not taken into consideration.

10 Pocket Verifier- Windows CE 3.12

Pocket Verifier helps accept credit cards and checks anywhere, on any Windows CE compatible PDA. It works with wired or wireless Internet connections and accepts credit cards and accepts checks electronically. It can accept a credit card and complete the transaction at a swap meet, construction site, even a moving vehicle. The above PDA application does not address security and privacy issues. A malicious user could be a threat to such a product.

11 Starcloser

STARCLOSER is the Sales Tool available for PDA’s that helps Close More Deals by tailoring the approach to the Personality of your audience. STARCLOSER works by taking the salesperson through brief multiple-choice questions about a customer's interpersonal style. Based on that process, STARCLOSER develops real-world approaches for building credibility, handling objections, areas to probe, and deal-closing suggestions, all based on the customer's personality. The StarCloser is a negotiator that aids the salesperson, but it does not help him with viewing product details and specifications of the product that he is trying to sell. Also the sales person will have to be trained on judging the appropriate answers for the questions. It is just the salesperson’s view, which may not be accurate.

12 Stronghold

The system consists of special software with Personal Digital Assistants (PDAs), allowing car dealers to record, communicate and access customer, sales and inventory information in real time. At dealer installations, the system has proven to help increase sales and to boost prospective customer “be-back” visits for additional closes. The company has developed this product, an integrated wireless technology that allows automobile dealers to capture a customer's purchasing requirements, search inventory at multiple locations, locate an appropriate vehicle in stock. This product cannot be used by customers to view car specifications or perform searches in the absence of the salesperson. Also security issues are not addressed. The customer cannot view the car locations and get similar details from the web.

13 CarSmart

is a website that acts as a car dealer. The features provided by it include buying and selling cars, payment calculator, and auto advisor. This is a website and may not be available on a handheld for use when a customer needs it. It does not give location of cars in a car lot and details about other vendor websites.

General plan OF WORK

1 Proposed Solution

A client GUI system will be developed to run on the PDA. A database will be used to maintain the inventory information that will be accessed by the PDA. Web services will be used for communication between the database and PDA. The PDA will give the user the ability to search the inventory based on different search criteria. Detailed results will be returned about the matching available vehicles and their location in the car lot. The customer to examine the vehicle can use this information, without being assisted by the sales agent. Confidential information about the best bargain price that can be offered is available to the sales agent. This will help the sales agent strike a deal with the customer without having to make any trips back to the office. Using this system will make sure that the sales agents and customers have access to the latest information. The PDA can also access information from outside partners regarding vehicles not available with the current dealer. This will increase the productivity and turn around for the auto dealer.

2 Methods & Procedures

1 Display()

This method/module will display the welcome screen and links to other screens like the screen for searching, login etc.

2 Login/Authentication

This module will handle the user login and authentication process. Login and Password information is accepted from the user and matched with the data stored in the database. If the data doesn't match, user will be prompted to login again. First time users of the system will be able to register.

3 Browse inventory

This module will allow the users to browse the inventory of the dealer. Users will be able to browse the inventory based on the car manufacturer.

4 Search the inventory

This module will allow the users to search for cars/vehicles based on different search criteria. This module will also handle displaying and sorting the results. Users will be able to add to and delete from their favorites list.

5 Find Availability

This module will communicate with other dealers/partners to find out information about the cars not available with the dealer.

6 DbConnect()

This method will be used to establish connection to the database.

7 InitSQL()

This method will be used to initialize all the sql needed, create statements.

8 ProcessResults()

This method will be used to execute the sql and process the results.

Proposed System

1 Domain Analysis

Both sales agents and customers can use the SELLSMART sales agent. This is a search and browse application that will provide the ability to browse the inventory of the host auto dealer and other car manufacturers. Users of this system can search for cars based on different search criteria. Search results with all the car details like model, price and specifications will be displayed on the PDA. If that car is available on the lot, car’s location will be given.

2 Requirements

1 Display Welcome Screen

The system should display the welcome screen and input text fields for login and password. This screen should also provide a link to search screen.

2 Registration and Authentication

For the new sales agents, system should take all their information, register them and allow them create username and password. System should authenticate the existing users’ login and password information. If the authentication fails, a message should be displayed and the user should be prompted for re-login.

3 Search Screen

Search screen should have several text fields to accept the search criteria. Search can be done any one or combination of price, car id, make, model and year. Users will have an option to specify the sort order.

4 Search Results Screen

Search Results screen should display the car id, make, model, year, price and car location if car is available with the dealer. Results will be sorted based on user’s sort choice. Default sort order will be on descending price.

5 Favorites List

Customer should be able to maintain his favorites list of cars. This favorites list is valid only for that session for customers that do not have accounts. If the customer wants to save his favorites, then customer should be prompted for account creation if he/she doesn’t already have an account.

6 Sales Agents Requirements

Sales agents should have access to confidential information such as best price that can be offered on a particular vehicle, any promotions available for this vehicle.

7 Information From Other Dealers

System should provide ability to communicate with other dealers/partners and get the availability information like colors, time to deliver etc.

8 Concurrent use

Multiple users should be able to use the system at the same time.

9 Portability

Though this is a PDA based system, it should be extendable to a web based system with minimal changes.

10 Reliability/Accuracy

The system should provide reliable and accurate information to the users.

11 Performance/SLA

The system should have reasonable response time. Response time should not increase with the increased number of users.

3 Business Model

This project’s business model is based on introducing the product into the market, offering product demos in trade fairs and auto shows, promoting the product using different media. Unique feature of this product is that it can communicate with other dealers/partners to find out availability information.

4 Stakeholders

Stakeholders of this system are auto dealers, sales agents and customers. Auto dealers can get better results from their sales agents by providing this system. Sales agents can be very productive and offer better service to their customers as they have all the information readily available. Customers can search for cars based on different search criteria and maintain a favorite list without needing the assistance of sales agents.

5 Proposed System Architecture

Figure 1: Proposed System Architecture for SellSmart

Timetable

|09/22/03 - 09/28/03 |Collecting requirements, preparing documentation. |

| | |

| |Submit Project1 Project proposal (09/29/03). |

|09/29/03 - 10/05/03 |Preparing initial design of the system, defining modules, sketching high-level user interface, |

| |and designing database. |

| | |

| |Studying related technologies, embedded VB, mobile .NET, PDA, web service, DCOM, CORBA and EJB |

| |etc. |

|10/06/03 - 10/12/03 |Identifying classes, defining function interfaces. |

| | |

| |Continuing with studying related technologies. |

|10/13/03 - 10/19/03 |Starting with developing small codes. |

| | |

| |Preparing concrete design of the system and documentation. |

| | |

| |Submit Project 2 system design done (10/20/03) |

|10/20/03 - 10/26/03 |Starting with the actual development of modules. |

|10/27/03 - 11/02/03 |Modules development continues |

| | |

| |Revisiting design to check whether we are working in right direction. |

|11/03/03 - 11/09/03 |Completing basic requirements of each module. |

| | |

| |Starting with initial testing. |

|11/10/03 - 11/16/03 |Continuing with module development. |

| | |

| |Preparing documentation and Submit Project 3 (11/13/03) |

|11/17/03 - 11/23/03 |Complete module development. |

| | |

| |Integrating modules. Starting with testing and debugging phase. |

|11/24/03 - 11/30/03 |Continuing with integrating and testing and enhancement. |

|12/01/03 - 12/07/03 |Preparing documentation. |

| | |

| |Submit Project 4 System Prototype II (12/07/03). |

|12/08/03 - 12/12/03 |Preparing documentation. |

| | |

| |Submit Project 5 Final Package (12/12/03) |

Bibilography

[1] Report: Chaotic Marketing Plagues Web Car Sales By Keith Regan



[2] PDA Car Lot Developed by Palmtree.ca Ltd.

[3] Car Buyer Calculator Developed by

[4] Component Technologies: Java Beans, COM, CORBA, RMI, EJB and the CORBA

[5] Component Model by Wolfgang Emmerich and Nima Kaveh, Dept of Computer Science, University College London

[6] Web Services: An Architectural Overview by Hansen, Santos, Pinto, Lanius, Massen.

[7] A Detailed Comparison of CORBA, DCOM and Java/RMI by Gopalan Suresh Raj -

[8] Mobile Computing in the retail Arena by Erica Newcomb, Toni Pashley, John Stasko

[9] Designing Interfaces for Handheld Computers by Philip B. Shoemaker, Palm computing. Published: ACM Tutorials, ISBN: 1-58113-158-5

[10] Java Native Interface: Technology Programming by Sheng Liang, Anand Palaniswamy

[11] Critique On Use of a CORBA/RMI Gateway: Characterization of Communication Overhead by Alessio Bechini, Pierfrancesco Foglia and Cosimo Antonio Prete

-----------------------

COM

CORBA

Adaptor

Component

EJB

[pic]

Web Service

PDA Client

Database

Different Car Vendors

Different Car Vendors

Partner Dealer III

Partner Dealer II

Partner Dealer I

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download