P1: 61
Nyberg WL040/Bidgoli-Vol III-Ch-11 July 11, 2003 11:49 Char Count= 0
PROTOTYPING FORE-COMMERCESYSTEMS 141possible. A prototype system with limited functionality
(just a few services and limited content) can be used to
test the integration of the chosen technologies.
Performance Testing. What is the average time required
to service a typical user transaction? Is the system’s
response time acceptable? How does system perfor-
mance vary as the transaction load is increased (e.g.,
in a simulated test environment)? Once a prototype
has been constructed, the architecture can be tested
via simulation of an ever-increasing number of page
and transaction requests. In the course of such an eval-
uation, resource bottlenecks (such as an overloaded
server) can be identified and addressed. If necessary,
the original design can be revised to better support
scalability (redundant servers with load balancing, mir-
rored databases, etc.).
Security Testing. Is the system vulnerable to any known ex-
ploits that could compromise system performance or
data integrity? Attack simulation software can be used
to test the security of the site once it has been proto-
typed. It is far better to uncover and address security
problems before the full-scale site has been built and
launched.Early prototyping can also be used for comparative
evaluation of competing technologies and to evaluate
whether specific emerging technologies are appropriate
for a given application. Several commercial Web applica-
tion environments are available, and each makes certain
assumptions about the operating environment (operating
system, platform, etc.). How these application paradigms
fit within a particular organization and integrate with ex-
isting legacy components is an important area for early
investigation.A Life-Cycle Model for Web Projects
An effective development model for Web-based e-com-
merce systems must support rapid development and con-
tinuous evolution. Web applications in particular are
subject to constant improvement and content update.
Copywriters, graphic designers, and Web designers pro-
vide content. Software engineers and developers pro-
vide the technical infrastructure. It is common that both
content and technology are developed, deployed, and
maintained simultaneously and somewhat independently.
Pressman (2001) proposes the WebE process, an iterative
life-cycle model that acknowledges the need to develop
content and technology in parallel. The WebE process in-
cludes the following cyclic activities:Formulation. Identify the goals of the application, the
users, and the scope of both content and function.
This process is like the normal requirements elicita-
tion and specification in typical software engineering,
but with important differences. It is important to iden-
tify all stakeholders associated with the application,
as well as the content providers. A typical application
requires assimilation of content from different organi-
zational units, from print and online resources, in vary-
ing formats. Identifying these requirements early is im-
portant for an accurate estimate of the effort to buildand maintain the site, which could involve significant
amounts of content conversion.
Planning. Allocate appropriate resources and decompose
development into appropriate phases, milestones, and
schedules. This process must take into account spe-
cial requirements regarding content acquisition, con-
version, translation, and localization.
Analysis. Understand the details of the system’s content,
user interactions, specific functionalities, and software
configuration. For each of these areas, construct an
analysis model that identifies all of the data objects
and operations on those objects.
Engineering. Design and implement the individual ele-
ments of the system. Content creation and system im-
plementation take place in parallel. Content creation
begins with content design, followed by a content pro-
duction process that encompasses acquisition, conver-
sion, translation and localization. System implementa-
tion includes architectural design, navigation design,
and interface design.
Page Generation and Testing. Construct the actual pages
for the site. All of the individual components (HTML
and JSP pages, applets, servlets, CGI scripts, etc.) are
integrated and tested by following all of the steps rep-
resented in the use case scenarios built during require-
ments formulation.
Customer Evaluation. Perform a detailed review of the ap-
plication with intended users and gather feedback for
next version of system.Although the full set of WebE activities is appropriate
for development of a complete application, the same steps
can also be followed in the construction of an initial pro-
totype system, with selection of an appropriate (reduced)
scope. In projects where I have used this approach for
prototyping, the initial focus is on the analysis and engi-
neering steps. The team creates a set of analysis models
(use case diagrams, usage scenarios, and a class diagram)
and embodies them in a set of prototype Web pages that
capture a proposed content style, navigation method(s),
and user interface elements. The architecture is usually
minimized or simulated. For example, the functions of
the application server and product database may be sim-
ulated by simple CGI scripts. The customer evaluation
step focuses on whether the proposed page design and
navigation capture the desired task flow and information
objectives. Customer feedback helps to refine the analysis
models before development begins.
A second iteration typically involves the creation of an
architecture prototype, where the prototype content and
navigation are deployed in an end-to-end system that in-
cludes the final application server and database modules.
The architecture prototype must contain only enough in-
formation content to test end-to-end integration; scaling
the system up to full content can happen in subsequent
iterations.
The WebE Process is flexible enough to support any
number of successive prototypes or incremental versions
leading up to a final product, while reinforcing the no-
tion that each revision to a system should take place in
a software engineering context. Each evolution includes