P1: 61
Nyberg WL040/Bidgoli-Vol III-Ch-11 July 11, 2003 11:49 Char Count= 0
THENATURE OFE-COMMERCESOFTWARE 137
is also extremely important in the presence of various soft-
ware risks that may not be well understood.
Requirements Analysis and “Design by Example”
Requirements analysis for e-commerce systems presents
two main challenges for the engineer: (a) it is generally
difficult for a customer to provide a detailed specification
for the visual components of a Web site (graphics con-
tent, layout, navigation, etc.); and (b) there are embed-
ded functional layers which the customer may take for
granted (database access, credit transactions, order ful-
fillment, etc.). Once a prototype has been constructed, it
is fairly easy for the customer to provide feedback on what
he or she likes or does not like about the proposed design
of the interface. The construction of a prototype can also
uncover a variety of assumptions regarding integration
with existing systems; in reviewing a prototype Web site,
the customer may realize that certain legacy functional-
ity is missing, links to other corporate sites are required,
other business units must be represented, etc. The cus-
tomer is typically less well informed about the technical
requirements of an application; the prototyping exercise
can be used as a vehicle for initiating contact with all of
the people “behind the scenes” who understand the low-
level integration requirements of a particular application,
including details of existing CRM and ERP systems, secu-
rity requirements, etc.
Understanding the Problem Domain
The software development life cycle proceeds smoothly
when the problem domain is well understood. When there
are gaps in the engineer’s understanding, even the best
practice can fail to produce the desired result. When a
development team begins working in a new area, proto-
typing is a useful way to immerse the team in the particu-
lars of the problem before the team members are asked to
design and implement a full-scale system. For example, a
development team that shifts from the creation of static
Web sites to the creation of shopping portals can take ad-
vantage of a prototyping exercise to learn the functional
requirements of a shopping portal in detail. An analogous
situation arises when a development team must learn a
new technology; even with a relatively stable technology
(e.g. Java), it is useful for the team to undertake a proto-
typing exercise as preparation for a full-scale project.
Reducing Technical Risk
Technical risks arise when new technology is used for the
first time, or a novel combination of technologies is tried
for the first time. In either situation, there is a signifi-
cant probability that unexpected problems will arise, and
a prototyping exercise can uncover these unknowns and
improve the accuracy of time and cost estimates for a full-
scale system. In the worst case, an initial technology deci-
sion may be abandoned as the result of a failed prototype,
but this is clearly preferable to canceling or renegotiating
a large-scale development contract that is already under
way. In the world of e-commerce software development,
technical risk is one of the biggest unknowns. As new
paradigms are being created for distributed client–server
solutions over the Internet, companies are compelled to
adopt new technology before it has been widely tested, in
order to remain competitive. Knowing when to invest in
rapid prototyping to alleviate technical risk is an impor-
tant strategic skill.
THE NATURE OF E-COMMERCE
SOFTWARE
Software development is an inherently risky endeavor.
Complex systems are difficult to deliver without signifi-
cant defects, even when adequate time and resources are
available. E-commerce systems are even more challeng-
ing, because they are subject to additional pressures that
increase the risks associated with software delivery.
Development on “Internet Time”
Unlike company-internal software development, which
proceeds according to schedules set within the organi-
zation, e-commerce systems are often developed under
the pressures of “Internet time”—the expectation is that
new technologies and solutions are rolled out every 3 to
6 months, under the credo “evolve rapidly, or die.” This
time pressure has an adverse effect on software develop-
ment. In the absence of adequate time to complete the
various phases in the software engineering life cycle, soft-
ware quality degrades as less time is spent on analysis,
design, and testing. With so little time available for de-
velopment, one might question whether prototyping is an
appropriate strategy, especially if a throwaway prototype
(and its associated “waste” of resources) is being consid-
ered. On the other hand, one might argue that prototyp-
ing is absolutely essential to keep the development team
on top of new technology, so that full-scale applications
can be designed, implemented, and deployed as quickly
as possible once the requirements are stabilized (Iansiti
& MacCormack, 1997). Because prototyping can alleviate
technical risk, it can improve the responsiveness of the
development team and help to keep final product delivery
on schedule, even if all requirements are not known until
close to the planned delivery date.
Evolution and Obsolescence
When software is developed quickly with an ad hoc or
nonexistent software process, the result is often code that
is poorly designed, poorly documented, and difficult to
maintain. When faced with a new project, the develop-
ment team is likely to resist working with the old system,
and will prefer to write a new system from scratch. The
pressures of rapid development can feed this vicious cycle,
and the result is a significant amount of time wasted on
reimplementing modules when previous modules could
have been reused—assuming they had been well-designed
and well-documented in the first place. If a prototype is
constructed in advance, a code review can be utilized
to identify which portions of the system are likely to be
general (and hence reusable). When the full-scale system
is constructed, the design and implementation of those
modules can be done in a manner that maximizes their
future reusability. In the future, the most successful soft-
ware companies will be those that minimize the amount of
new code that is created in each new application, through