The Internet Encyclopedia (Volume 3)

(coco) #1

P1: 61


Nyberg WL040/Bidgoli-Vol III-Ch-11 July 11, 2003 11:49 Char Count= 0


PrototypingPrototyping


Eric H. Nyberg,Carnegie Mellon University

Overview of the Software Life Cycle 135
Requirements Elicitation and Specification 135
System Analysis 135
System Design 135
Implementation, Testing, and Maintenance 135
The Role of Prototyping in Software Development 136
Approaches to Prototyping 136
Why Do We Do Prototyping? 136
The Nature of E-commerce Software 137
Development on “Internet Time” 137
Evolution and Obsolescence 137
Architectural Complexity 138
Technological Risk 138

Prototyping for E-commerce Systems 138
Use Case Scenarios 138
Interface Prototypes 139
Content Prototypes 139
Architecture Prototypes 140
A Life-Cycle Model for Web Projects 141
Flexible Product Development and the
Evolutionary Development Model 142
Conclusion 143
Glossary 143
Cross References 144
References 144
Further Reading 144

OVERVIEW OF THE SOFTWARE
LIFE CYCLE
The conception, implementation, and evolution of soft-
ware will follow a particular life cycle, depending on the
problem to be solved, the software and hardware chosen,
and the inevitable changes to system requirements and
functionality that happen over time. It can be extremely
useful to construct a prototype system in advance of a
full-scale implementation; because a prototype typically
addresses all of the important aspects of a system to be
built, it can be a means to sharpen the system require-
ments and focus the development team on the most im-
portant challenges and risks. In order to understand the
role that prototyping can play in an e-commerce applica-
tion, it is first necessary to understand the basic steps in
the software life cycle.

Requirements Elicitation and Specification
The software process begins with requirements elicitation
and specification. Through a set of communications with
customer representatives, the software engineers begin to
specify the system to be built by documenting its desired
characteristics: functions provided to the user, user inter-
face, interfaces to other software systems, desired perfor-
mance criteria, required robustness, error handling and
security, update mechanism(s), deployment platform(s),
and so on. The result is a formal document, referred to as
the Requirements Specification, which is typically used as
the basis for detailed planning and contracting with the
customer.

System Analysis
During the analysis phase, the engineers model the system
by identifying all of the data objects and operations in the
problem domain. In object-oriented analysis, domain data
objects are represented in an initial class diagram, com-
monly constructed using the Unified Modeling Language

(UML) (Pooley & Stevens, 1999). The functions of the sys-
tem are broken down into particular interactions with the
user, which may imply embedded interactions with re-
mote systems (database lookup, credit transactions, etc.).
The system’s functions can be represented using a UML
use case diagram. For each function or use case, the en-
gineer may write several use case scenarios, prose narra-
tives that describe in detail how the system will carry out
a particular function under a variety of circumstances.
Use case scenarios include “expected” scenarios, which
describe the typical or usual case where no errors or un-
expected conditions occur; and “unexpected” scenarios,
which cover what might go wrong during the invocation
of a particular function (page not found, invalid password,
network error, etc.) (Pressman, 2001).

System Design
The design phase maps the functions described during
the analysis phase into (a) a set of software modules and
(b) a software architecture that integrates the modules
into a complete system. At the module level, design has
two aspects: (a) partitioning the system’s functionality
into specific modules (modular design) and (b) specifying
the particular algorithms and data structures to be used
by each individual module (detailed design). In object-
oriented development, modules are typically classes in
an object-oriented programming language such as Java.
The artifacts produced by the engineer during the design
phase might include a detailed UML class diagram, skele-
tal class files with documentation for data members and
methods, and some form of architecture diagram showing
how the modules are grouped into partitions (packages)
and layers (Bruegge & Dutoit, 2000).

Implementation, Testing, and Maintenance
Once the design is complete, the system developers code
the modules according to the design specifications. Imple-
mentation should begin with the creation of unit tests for

135
Free download pdf