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
SELLSMART© PROJECT PROPOSAL
September 27, 2003
Table Of Contents
1
INTRODUCTION ................................................................................................... 4
1.1
1.2
1.3
1.4
2
PROJECT GOAL AND OBJECTIVES ............................................................... 5
2.1
2.2
2.3
3
OVERALL GOAL ........................................................................................................... 5
SPECIFIC OBJECTIVE .................................................................................................... 5
SIGNIFICANCE .............................................................................................................. 6
PROJECT BACKGROUND .................................................................................. 7
3.1
4
PURPOSE OF THIS DOCUMENT ...................................................................................... 4
SCOPE OF THIS DOCUMENT .......................................................................................... 4
BRIEF OVERVIEW ........................................................................................................ 4
BUSINESS CONTEXT..................................................................................................... 4
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
GENERAL PLAN OF WORK............................................................................. 11
4.1
4.2
PROPOSED SOLUTION ................................................................................................ 11
METHODS & PROCEDURES ........................................................................................ 11
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
5
Display() ................................................................................................................................. 11
Login/Authentication .............................................................................................................. 11
Browse inventory .................................................................................................................... 11
Search the inventory ............................................................................................................... 11
Find Availability ..................................................................................................................... 11
DbConnect() ........................................................................................................................... 11
InitSQL() ................................................................................................................................ 12
ProcessResults() ...................................................................................................................... 12
PROPOSED SYSTEM .......................................................................................... 13
5.1
5.2
DOMAIN ANALYSIS.................................................................................................... 13
REQUIREMENTS ......................................................................................................... 13
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
Display Welcome Screen ........................................................................................................ 13
Registration and Authentication .............................................................................................. 13
Search Screen.......................................................................................................................... 13
Search Results Screen ............................................................................................................. 13
Favorites List .......................................................................................................................... 13
Sales Agents Reqs ................................................................................................................... 13
Information From Other Dealers ............................................................................................. 14
DESIGEEKS®
2
SELLSMART© PROJECT PROPOSAL
5.3
5.4
5.5
September 27, 2003
5.2.8
Concurrent use ........................................................................................................................ 14
5.2.9
Portability ............................................................................................................................... 14
5.2.10
Reliability/Accuracy ............................................................................................................... 14
5.2.11
Performance/SLA ................................................................................................................... 14
BUSINESS MODEL ...................................................................................................... 14
STAKEHOLDERS ......................................................................................................... 14
PROPOSED SYSTEM ARCHITECTURE.......................................................................... 15
6
TIMETABLE ......................................................................................................... 16
7
BIBILOGRAPHY ................................................................................................. 17
DESIGEEKS®
3
SELLSMART© PROJECT PROPOSAL
September 27, 2003
11 IIN
NTTR
RO
OD
DU
UC
CTTIIO
ON
N
1.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.
1.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.
1.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.
1.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.
DESIGEEKS®
4
SELLSMART© PROJECT PROPOSAL
September 27, 2003
22 P
PR
RO
OJJE
EC
CTT G
GO
OA
ALL A
AN
ND
DO
OB
BJJE
EC
CTTIIV
VE
ES
S
2.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.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
DESIGEEKS®
5
SELLSMART© PROJECT PROPOSAL
September 27, 2003
medium to provide bi-directional communication between the client application and the server
application, which will be doing the bulk of the processing.
2.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.
DESIGEEKS®
6
SELLSMART© PROJECT PROPOSAL
September 27, 2003
33 P
PR
RO
OJJE
EC
CTT B
BA
AC
CK
KG
GR
RO
OU
UN
ND
D
3.1
WORK DONE BY OTHERS (CRITIQUES)
In this section, we present an analysis of our research on products parallel to SELLSMART. (Our
Competitors!!!)
3.1.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.
3.1.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.1.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
DESIGEEKS®
7
SELLSMART© PROJECT PROPOSAL
September 27, 2003
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.
3.1.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.
3.1.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.
3.1.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
DESIGEEKS®
8
SELLSMART© PROJECT PROPOSAL
September 27, 2003
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.
3.1.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.
3.1.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.
3.1.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
DESIGEEKS®
9
SELLSMART© PROJECT PROPOSAL
September 27, 2003
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.
3.1.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.
3.1.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.
3.1.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.
3.1.13 CarSmart
CarSmart.com 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.
DESIGEEKS®
10
SELLSMART© PROJECT PROPOSAL
September 27, 2003
44 G
GE
EN
NE
ER
RA
ALL P
PLLA
AN
NO
OFF W
WO
OR
RK
K
4.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.
4.2
METHODS & PROCEDURES
4.2.1
Display()
This method/module will display the welcome screen and links to other screens like the screen
for searching, login etc.
4.2.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.
4.2.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.2.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.
4.2.5
Find Availability
This module will communicate with other dealers/partners to find out information about the cars
not available with the dealer.
4.2.6
DbConnect()
This method will be used to establish connection to the database.
DESIGEEKS®
11
SELLSMART© PROJECT PROPOSAL
4.2.7
September 27, 2003
InitSQL()
This method will be used to initialize all the sql needed, create statements.
4.2.8
ProcessResults()
This method will be used to execute the sql and process the results.
DESIGEEKS®
12
SELLSMART© PROJECT PROPOSAL
September 27, 2003
55 P
PR
RO
OP
PO
OS
SE
ED
DS
SY
YS
STTE
EM
M
5.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.
5.2
REQUIREMENTS
5.2.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.
5.2.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.
5.2.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.
5.2.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.2.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.
5.2.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.
DESIGEEKS®
13
SELLSMART© PROJECT PROPOSAL
5.2.7
September 27, 2003
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.
5.2.8
Concurrent use
Multiple users should be able to use the system at the same time.
5.2.9
Portability
Though this is a PDA based system, it should be extendable to a web based system with
minimal changes.
5.2.10 Reliability/Accuracy
The system should provide reliable and accurate information to the users.
5.2.11 Performance/SLA
The system should have reasonable response time. Response time should not increase with the
increased number of users.
5.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.
5.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.
DESIGEEKS®
14
SELLSMART© PROJECT PROPOSAL
5.5
September 27, 2003
PROPOSED SYSTEM ARCHITECTURE
Different
Car Vendors
Different
Car Vendors
Partner
Dealer I
Partner
Dealer II
E
EJJB
B
C
CO
OM
M
Partner
Dealer III
C
CO
OR
RB
BA
A
ADAPTOR
COMPONENT
Web Service
Database
PDA
Client
Figure 1: Proposed System Architecture for SELLSMART
DESIGEEKS®
15
SELLSMART© PROJECT PROPOSAL
September 27, 2003
66 TTIIM
ME
ETTA
AB
BLLE
E
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)
DESIGEEKS®
16
SELLSMART© PROJECT PROPOSAL
September 27, 2003
77 B
BIIB
BIILLO
OG
GR
RA
AP
PH
HY
Y
[1]
Report: Chaotic Marketing Plagues Web Car Sales By Keith Regan
http://www.ecommercetimes.com/perl/story/7453.html
[2]
PDA Car Lot Developed by Palmtree.ca Ltd.
[3]
Car
Buyer
Calculator
http://www.pocketgear.com
[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 - http://my.execpc.com/~gopalan/misc/compare.html
[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
DESIGEEKS®
Developed
by
pocketgear.com
17