![CHAPTER 1 WEB-BASED SYSTEMS
2
The Web has become an indispensable technology for business, commerce,
communication, education, engineering, entertainment, finance, government, in-
dustry, media, medicine, politics, science, and transportation—to name just a few
areas that impact your life. But being an “indispensable technology” only scratches
the surface of the Web’s impact on each of us. It has changed the ways in which
we buy products (e-commerce), meet people (online dating), understand the world
(portals), acquire our news (online media), voice our opinions (blogs), entertain
ourselves (everything from music downloads to online casinos), and go to school
(online learning).
All of these impacts have one thing in common—they need a delivery vehicle
that takes raw information associated with the area of interest; structures it in a
way that is meaningful; builds a packaged presentation that is organized, aesthetic,
ergonomic, and interactive (where required); and delivers it to your Web browser in
a manner that initiates a conversation.
The conversation between you and a Web application can be passive or active.
In a passive conversation, you select the information that is to be presented, but
have no direct control over its volume, type, or structure. In an active conversation,
you provide input so that the information that is presented is customized to meet
your needs specifically.
The vehicle that acquires information, structures it, builds a packaged pre-
sentation, and delivers it is called a Web application (WebApp). When a WebApp is
combined with client and server hardware, operating systems, network software,
and browsers, a Web-based system emerges.
Web Applications
In the early days of the World Wide Web (circa 1990 to 1995), “websites” consisted
of little more than a set of linked hypertext files that presented information using
text and limited graphics. As time passed, Hypertext Markup Language (HTML)
was augmented by development tools and technologies [e.g., Extensible Markup
Language (XML), Java] that enabled Web engineers to provide both client-side and
server-side computing capability along with content. Web-based systems and ap-
plications1
were born. Today, WebApps have evolved into sophisticated computing
tools that not only provide stand-alone functionality to the end user, but also have
been integrated with corporate and governmental databases and applications.
1 In the context of this book, the term Web application (WebApp) encompasses everything from
a simple Web page that might help a consumer compute an automobile lease payment to a
comprehensive website that provides complete travel services for business people and vaca-
tioners. Included within this category are complete websites, specialized functionality within
websites, and information-processing applications that reside on the Internet or on an Intranet
or Extranet.
pre23291_ch01.indd 2
pre23291_ch01.indd 2 1/2/08 3:43:26 PM
1/2/08 3:43:26 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-21-320.jpg)
![CHAPTER 1 WEB-BASED SYSTEMS 3
Let’s Introduce a Case Study
You’ve been approached by CPI Corporation, a (fictional) company that builds, mar-
kets, sells, and monitors security systems for homes and small businesses. CPI
has no Web presence and wants to roll out a “significant” website that will coin-
cide with the introduction of a new line of security sensors and a set of radically
new Web-based services. They want your help in the development of the WebApp,
which is called SafeHomeAssured.com, and at the same time for you to assist them as
they create new Web services that will increase their market share.
You have been asked to attend a meeting in which basic ideas are discussed.
During the meeting you learn that CPI has engineered a compact, wireless sensor-
controller that will become the core element in a new line of commercial and resi-
dential security systems that it intends to call SafeHome. A snippet of conversation
from the meeting is depicted in the sidebar.
A Project Begins
The scene: Meeting room at CPI
Corporation, a (fictional) company
that makes consumer products for home and commer-
cial use
The players: A senior business manager; a product
development manager; a marketing manager; an
engineering manager; and you, the Web engineering
expert
The conversation:
Business manager (to product manager):
Okay, what’s this I hear about your folks developing
a what? A generic universal wireless box?
Product manager: It’s pretty cool . . . about the
size of a small matchbook . . . we can attach it to sen-
sors of all kinds, a digital camera, just about anything
using an IEEE wireless protocol. It allows us to access
the device without wires. We think it’ll lead to a whole
new generation of products.
Business manager (looking at the marketing
manager): You agree?
Marketing manager: I do. In fact, with sales as
flat as they’ve been this year, we need something new.
We’ve been doing a little market research, and we
think we’ve got a line of products and services that
could be big.
Business manager: How big . . . bottom line big?
Marketing manager: It’s a whole new generation
of what we call “home management products.” We
call ’em SafeHome. They use the new wireless inter-
face, provide homeowners or small-business people
with a system that’s controlled by their PC via the
Internet—home security, home surveillance, appliance
and device control—you know, turn down the home
air conditioner while you’re driving home, that sort of
thing. We’re also thinking about video monitoring and
control within a house or business. Just as important,
we intend to vertically integrate the product into our
monitoring services, allowing customers to access their
account via the Web and determine things like when
the system is armed or disarmed, what “events” have
occurred over a defined time period . . . things like
that. We also intend to do most of our maintenance
diagnostics via the Web.
Product manager: Engineering’s done a techni-
cal feasibility study of these ideas. They’re doable at
relatively low cost. Most hardware is off-the-shelf. Soft-
ware for the Web is an issue, but it’s nothing that we
can’t get done. We already registered a domain . . .
SafeHomeAssured.com.
[All CPI managers look directly at you and smile.]
Business manager: Interesting. Now, I asked
about the bottom line.
(continued)
SAFEHOME
pre23291_ch01.indd 3
pre23291_ch01.indd 3 1/2/08 3:43:27 PM
1/2/08 3:43:27 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-22-320.jpg)
![CHAPTER 1 WEB-BASED SYSTEMS
8
But CPI has no meaningful Web presence, not to mention written requirements
for what the SafeHomeAssured.com WebApp is to be, and it doesn’t yet have a partic-
ularly sophisticated understanding of the true capabilities of the Web. For example,
the people at CPI look at you blankly when you mention the possibility of eventu-
ally—in a year or two—having an interface to clients’ security systems through
a virtual world containing three-dimensional (3D) renditions of their homes (like
Second Life4
). You decide to provide them with a quick example website, if only to
get started. The actual SafeHomeAssured.com WebApp will evolve in stages that we’ll
call WebApp increments. As the WebApp evolves, it will take on the characteristics
of the categories5
that follow:
Informational WebApps. You decide to build a home page and a few
supplementary pages that describe CPI and its products and services. What
you’ve done is to create an informational WebApp—one that contains read-
only content with simple navigation and links.
Download WebApps. A few weeks later, you begin to add content that
describes SafeHome sensors and other security system hardware. CPI pro-
vides you with PDF (Portable Document Format) specification files describing
each. You add a capability that allows visitors to the SafeHomeAssured.com
WebApp to download the product specs. The WebApp now incorporates
informational and download capability.
Customizable WebApps. As you learn more from CPI stakeholders, it be-
comes apparent that you have four kinds of potential end users: homeown-
ers, small-business owners, CPI customer service staff, and CPI technical
service staff. You want to tailor the content presented at the website to the
specific needs of each customer type, using jargon and presenting content
that will meet their needs. You do a major overhaul of your initial WebApp
and create a new one that is customizable for each user.
Interaction WebApps. Traffic increases rapidly, and before long you have
hundreds of visitors each day (after all, people worry about effective solu-
tions for home and business security). You want to create a feeling of com-
munity among your visitors—a place where people can chat, ask and answer
questions, provide product testimonials, and the like. You decide to imple-
ment an extension to SafeHomeAssured.com that supports a chat room feature.
You’ve now provided an interactive component for your WebApp.
User Input WebApps. CPI management wants to move away from e-mail
and telephone calls requesting quotes for specific security products. You
4 See http://secondlife.com/.
5 The WebApp categories that follow have been adapted from [Dar99].
pre23291_ch01.indd 8
pre23291_ch01.indd 8 1/2/08 3:43:30 PM
1/2/08 3:43:30 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-27-320.jpg)
![CHAPTER 1 WEB-BASED SYSTEMS 11
to collect crime-related statistics by neighborhood in cities across the country, then
use Web-based demographic data to target households in those neighborhoods
that are potential purchasers of SafeHome, and, finally, develop a targeted market-
ing campaign that focuses on those households.
Today, this Internet sea washes over each of us. We surf (it’s interesting that
this term is used) looking for data, information, and knowledge. But we almost
never get a glimpse at the consciousness that seethes beneath the surface. As time
passes and we move further into the twenty-first century, Web engineers will begin
to create systems that will enable all of us to extract data, information, and knowl-
edge in novel ways—to do more than skim across the surface.
Most of this book is about a philosophy, but one of a more pragmatic kind. In
the chapters that follow, we’ll discuss Web engineering—a framework that enables
the creation of WebApps that may ultimately guide us along the journey toward a
global consciousness.
Reference
[Dar00] Dart, S., Configuration Management: The Missing Link in Web Engineering,
Artech House, 2000.
pre23291_ch01.indd 11
pre23291_ch01.indd 11 1/2/08 3:43:31 PM
1/2/08 3:43:31 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-30-320.jpg)
![CHAPTER 2 WEB ENGINEERING 13
completely unreasonable), and stakeholders1
keep changing their minds even as
they demand rapid delivery. Customers care about a WebApp that’s delivered when
they need it, not about the work that goes into creating a deliverable WebApp. With
all this in mind, a WebE team must emphasize agility. Ivar Jacobson [Jac02] pro-
vides a useful discussion of the concept:
An agile team is a nimble team able to appropriately respond to changes. Change is
what software development is very much about. Changes in the software being built,
changes to the team members, changes because of new technology, changes of all
kinds that may have an impact on the product they build or the project that creates the
product. Support for changes should be built-in everything we do in software, some-
thing we embrace because it is the heart and soul of software. An agile team recog-
nizes that software is developed by individuals working in teams and that the skills of
these people, their ability to collaborate is at the core for the success of the project.
In Jacobson’s view, the pervasiveness of change is the primary driver for agility.
Web engineers must be quick on their feet if they are to accommodate the rapid
changes that Jacobson describes.
What Is a WebE Framework?
A framework2
establishes the foundation for a complete Web engineering pro-
cess by identifying a small number of framework activities that are applicable to all
WebApp projects, regardless of their size or complexity. In addition, the framework
encompasses a set of umbrella activities that are applicable across the entire WebE
process.
Referring to Figure 2.1, each framework activity is populated by a set of Web
engineering actions—a collection of related tasks that produces a work product
(e.g., design is a WebE action). Each action is populated with individual work tasks
that accomplish some part of the work implied by the action.
The following WebE activities are part of a generic framework and are appli-
cable to the vast majority of WebApp projects:
Communication. Involves heavy interaction and collaboration with the
customer (and other stakeholders) and encompasses requirements gathering
and other related activities.
Planning, Establishes an incremental plan3
for the WebE work. It describes
the WebE actions that will occur, the technical tasks to be conducted, the
1 A stakeholder is anyone who has a stake in the successful outcome of the project—business
managers, end users, Web engineers, support people, and the like. Rob Thomsett jokes that “a
stakeholder is a person holding a large and sharp stake . . . If you don’t look after your stake-
holders, you know where the stake will end up.”
2 The phrases process, process model, and process framework are also used in this context.
3 An incremental plan assumes that the WebApp is to be delivered in a series of “increments” that
provide successively more robust sets of requirements with each delivery.
pre23291_ch02.indd 13
pre23291_ch02.indd 13 1/2/08 3:43:46 PM
1/2/08 3:43:46 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-32-320.jpg)
![CHAPTER 2 WEB ENGINEERING 15
These five generic framework activities can be used during the development of
WebApps of all sizes and complexity. The details of the framework can be quite dif-
ferent in each case, but the framework activities remain the same.
Referring again to Figure 2.1, each Web engineering action is represented by a
set of tasks—each a collection of Web engineering work tasks, related work prod-
ucts, quality assurance points, and project milestones. The set of tasks that best
accommodates the needs of the project and the characteristics of the team is cho-
sen. This implies that a Web engineering action (e.g., requirements gathering) can
be adapted to the specific needs of the WebApp project and the characteristics of
the project team.
Umbrella activities (e.g., risk management, quality assurance, content manage-
ment) are applied throughout the WebE process and are discussed in detail later in
this book.
Intelligent application of any framework must recognize that adaptation (to the
problem, to the project, to the team, and to the organizational culture) is essential
for success. Adaptation affects each of the following framework characteristics:
• Overall flow of activities, actions, and tasks and the interdependencies
among them
• Degree to which work tasks are defined within each framework activity
• Degree to which work products are identified and required
• Manner in which quality assurance activities are applied
• Manner in which project tracking and control activities are applied
• Overall degree of detail and rigor with which the process is described
• Degree to which customers and other stakeholders are involved with the
project
• Level of autonomy given to the software project team
• Degree to which team organization and roles are prescribed
What Principles Should You Follow as You Adapt the Framework?
The adapted framework for WebE should emphasize project agility and follow a set
of 12 agility principles adopted by the Agile Alliance [Agi03]:
• Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
pre23291_ch02.indd 15
pre23291_ch02.indd 15 1/2/08 3:43:47 PM
1/2/08 3:43:47 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-34-320.jpg)
![CHAPTER 2 WEB ENGINEERING 17
How Does Software Engineering Come into Play?
In a virtual round table published in IEEE Software [Pre98], Roger staked out a posi-
tion that couples Web engineering and software engineering:
It seems to me that just about any important product or system is worth engineering.
Before you start building it, you’d better understand the problem, design a workable
solution, implement it in a solid way, and test it thoroughly. You should probably also
control changes to it as you work and have some mechanism for ensuring the end
result’s quality. Many Web developers don’t argue with this; they just think their world
is really different and that conventional software engineering approaches simply don’t
apply.
His argument was that software engineering principles, concepts, and methods
can be applied to Web development, but their application requires a somewhat dif-
ferent approach than their use during the development of conventional software-
based systems.
Software engineering5
is a philosophy, incorporating a process, a collec-
tion of methods, and a tool set, that has been adopted wherever software is built.
And yet, software engineering continues to have a public relations problem with
at least some (often vocal) software developers. Some developers think that soft-
ware engineering is ponderous and slow. They believe that it is about generating
documents—lots of documents. They argue that it overburdens a software team
with planning and places unfair management restrictions on the team. The prob-
lem is: they’re wrong. If software engineering is applied incorrectly, it can be the
things that some people worry about, but if it is applied in an agile manner, it can
only serve to improve the quality and speed the delivery of each system that is built
using it.
Software engineering is a layered technology. Referring to Figure 2.2, its foun-
dation is an organizational commitment to quality6
—a promise to foster a con-
tinuous process improvement culture. It is this culture that ultimately leads to the
development of increasingly more effective approaches to software engineering.
The process layer is the glue that holds the technology layers together and en-
ables rational and timely development of computer software. It forms the basis
for management control of software projects and establishes the context in which
technical methods are applied, work products (e.g., models and documents) are
produced, milestones are established, quality is ensured, and change is properly
managed.
5 For a reasonably comprehensive discussion of software engineering, we recommend that you
examine Software Engineering: A Practitioner’s Approach [Pre09].
6 Total quality management, Six Sigma, and ISO 9001 are typical of corporate programs that foster
a quality culture.
pre23291_ch02.indd 17
pre23291_ch02.indd 17 1/2/08 3:43:48 PM
1/2/08 3:43:48 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-36-320.jpg)
![18
Software engineering methods provide the technical how-to’s for building
software. Methods encompass a broad array of actions and tasks that include
communication, requirements analysis, design modeling, program construction,
testing, and support. These methods rely on a set of basic principles that govern
each area of the technology and include modeling activities and other descriptive
techniques.
Software engineering tools provide automated or semiautomated support for
the process and the methods. When tools are integrated so that information cre-
ated by one tool can be used by another, an automated environment for the sup-
port of software engineering is established.
Why Is WebE Process Agility So Important?
We have already noted that a WebE process model (we referred to this as a frame-
work earlier in this chapter) should be agile. This implies a lean engineering
approach that incorporates rapid development cycles. Each cycle results in the
deployment of a WebApp increment. Aoyama [Aoy98] describes the motivation for
the agile approach in the following manner:
The Internet changed software development’s top priority from what to when. Reduced
time-to-market has become the competitive edge that leading companies strive for.
Thus, reducing the development cycle is now one of software engineering’s most im-
portant missions.
Even when rapid cycle times dominate development thinking, it is important to
recognize that the WebE framework must be defined within a process that: (1) em-
braces change, (2) encourages the creativity and independence of development
staff and strong interaction with WebApp stakeholders, (3) builds systems using
small development teams, and (4) emphasizes incremental development using
short development cycles.
In Chapter 3 we’ll discuss the details of a process framework that can work
well for many WebE projects. For now, you should recognize that agility will be the
underlying philosophy for our Web engineering work. But you should also under-
stand that an emphasis on agile development in no way mitigates the need for a
disciplined engineering approach.
FIGURE 2.2
Software
engineering
layers.
Tools
Methods
Process
A quality focus
CHAPTER 2 WEB ENGINEERING
pre23291_ch02.indd 18
pre23291_ch02.indd 18 1/2/08 3:43:48 PM
1/2/08 3:43:48 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-37-320.jpg)
![CHAPTER 2 WEB ENGINEERING
20
But tools and technology cannot be used in a vacuum. If you don’t really un-
derstand the problem, if you have no way of accommodating changes that will in-
variably occur, if you haven’t spent some time laying out a viable solution, if you
have no intention of ensuring the “solution” that you’ve generated (using powerful
tools) meets the needs of your stakeholders, then you’re working in a vacuum. And
that’s a recipe for disaster!
What we’re trying to say is this: Tools and technology are very important, but
they’ll work well only if they’re used within the context of an agile framework for Web
engineering and in conjunction with proven methods for understanding the problem,
designing a solution, and testing it thoroughly.
A vast array of tools and technology has evolved over the past decade as
WebApps have become more sophisticated and pervasive. These technologies en-
compass a wide range of content description and modeling languages [e.g., HTML,
virtual reality modeling language (VRML), XML], programming languages (e.g.,
Java), component-based development resources [e.g., Common Object Request Bro-
ker Architecture (CORBA), Component Object Model (COM) architecture, ActiveX,
.NET], browsers, multimedia tools, site authoring tools, database connectivity tools,
security tools, servers and server utilities, and site management and analysis tools.
An overview of some of the more important tools and technology for Web
engineering is presented in Chapter 14. For a more comprehensive discussion,
you should visit one or more of the following websites: Web Developer’s Virtual Li-
brary (www.wdvl.com), WebDeveloper (www.webdeveloper.com), Developer Shed (www.
devshed.com), Webknowhow.net (www.webknowhow.net), or WebReference (www.
webreference.com).
Agreeing on a Process
SAFEHOME
The scene: Meeting room for the
Web engineering group at CPI Cor-
poration prior to the initiation of the project
The players: Technical manager, WebE team
members
The conversation:
Technical manager (to the team): So, let’s reca-
pitulate. We’ve been tapped to build SafeHome
Assured.com. It’s the biggest and certainly the most
visible WebApp we’ve ever tried to construct. No
doubt, we’ve got a lot of work to do to simply define
the thing, but I’d like you guys to begin thinking about
how you’re going to approach the engineering part of
this project.
Team member 1: Seems like we’ve been pretty
disorganized in our approach to Web projects in the
past.
Team member 2: I don’t agree; we always got
product out the door.
Technical manager: True, but not without a lot of
grief, and this project looks like it’s bigger and more
complex than anything we’ve done in the past.
pre23291_ch02.indd 20
pre23291_ch02.indd 20 1/2/08 3:43:49 PM
1/2/08 3:43:49 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-39-320.jpg)
![CHAPTER 2 WEB ENGINEERING 21
Web Engineering Best Practices
Before we proceed into the core chapters of this book, some plain talk is in order.
We recognize that you may choose not to use the WebE process framework and
methods that we’ll discuss in detail throughout the remainder of this book. We
know that Web engineering teams are sometimes under enormous time pressure
and will try to take shortcuts (even if these are ill advised and result in more de-
velopment effort, not less). We also accept the fact that some WebE teams want to
keep things very informal and reject the notion of a process framework and defined
methods as a matter of philosophy. We think that kind of reasoning is erroneous,
but it’s your call.
What we do hope is that you spend enough time in the remaining chapters
to assess each of the practices that we describe, accepting those that seem ap-
plicable and rejecting those that don’t. As an absolute minimum, we hope that you
and your colleagues will adopt the following best practices whenever you build
industry-quality WebApps:
1. Take the time to understand business needs and product objec-
tives, even if the details of the WebApp are vague. Many WebApp
developers erroneously believe that vague requirements (which are quite
common) relieve them from the need to be sure that the system they are
about to engineer has a legitimate business purpose. The end result is
(too often) good technical work that results in the wrong system being built
for the wrong reasons and for the wrong audience. If stakeholders cannot
enunciate a business need for the WebApp, proceed with extreme caution.
SAFEHOME (CONTINUED)
Team member 3: Doesn’t look that hard, but I agree
. . . our ad hoc approach to past projects might not
work here, particularly if we have a very tight time line.
Technical manager (smiling): I want to be a bit
more professional in our approach. I went to a short
course last week and learned a lot about Web engi-
neering . . . good stuff. We need a process here.
Team member 2 (with a frown): Process? My
job is to build WebApps, not push paper around.
Technical manager: Give it a chance before you
go negative on me. Here’s what I mean. [He proceeds
to describe the process framework described in this
chapter and the agile Web engineering philosophy
presented to this point.] So anyway, it seems to me
that it’s possible to implement an agile process with
straightforward activities that won’t result in “pushing
a lot of paper around.”
Team member 1: Yeah, agility sounds good, and
the five steps, er, activities, you mentioned are just
common sense.
Team member 2: I agree, they’re common sense.
That’s why I don’t think we need to implement a
process.
Team member 3 (laughing): Yeah, but common
sense isn’t always so common. Why don’t we give this
a chance?
pre23291_ch02.indd 21
pre23291_ch02.indd 21 1/2/08 3:43:51 PM
1/2/08 3:43:51 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-40-320.jpg)
![CHAPTER 2 WEB ENGINEERING 23
Where We’ve Been . . . Where We’re Going
As we begin our consideration of Web engineering and the process framework
that acts as its foundation, agility becomes a very important concept. As a Web
engineer, you have to be quick on your feet. Your job is to build high-quality
WebApps—quickly. But as you do this, you have to accommodate a system that
continues to evolve as work is conducted. You have to adapt a generic framework
for each WebApp increment and integrate a collection of WebE methods and tools
into the framework. You have to follow a set of agility principles and a collection of
best practices that guide the team toward success.
As we move into Chapter 3, you’ll learn more about the WebE process frame-
work. More importantly, we suggest a set of WebE actions and tasks that can serve
as a basis for adapting the framework to the very specific needs of the problem, the
people, and the project.
References
[Agi03] The Agile Alliance Home Page, www.agilealliance.org/home (accessed July
24, 2007).
[Aoy98] Aoyama, M., “Web-based Agile Software Development,” IEEE Computer,
November/December 1998, pp. 56–65.
[Fow01] Fowler, M., and J. Highsmith, “The Agile Manifesto,” Software Develop-
ment Magazine, August 2001, www.sdmagazine.com/documents/s=844/sdm0108a/
0108a.htm (accessed July 24, 2007).
[Jac02] Jacobson, I., “A Resounding ‘Yes’ to Agile Processes—But Also More,”
Cutter IT Journal, vol. 15, no. 1, January 2002, pp. 18–24.
[Pre98] Pressman, R. S. (moderator), “Can Internet-Based Applications Be Engi-
neered?” IEEE Software, September 1998, pp. 104–110.
[Pre09] Pressman, R. S., Software Engineering: A Practitioner’s Approach, 7th ed.,
McGraw-Hill, 2009.
pre23291_ch02.indd 23
pre23291_ch02.indd 23 1/2/08 3:43:52 PM
1/2/08 3:43:52 PM](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-42-320.jpg)
![Harold demurred, as being unprofessional.
"Then come to attend me," eagerly responded Miss Geare. "I'm
often rather ailing; and you can give Bijou a look at the same time."
She looked at him so pleadingly that he could not find it in his heart
to say no. She brightened up at his consent, and asked for a cab, in
which to take home her injured darling, and then laid a sovereign
and a shilling on the table.
"I don't think I am entitled to charge for attending the dog," said
Harold, crimsoning. "Certainly, this is far too much."
"Watson, the veterinary surgeon, never would have charged a
guinea," indignantly added Miss Pepper; but Miss Geare was
resolute, and when she had departed, it was certainly pleasant to
see the gold piece on the table, sovereigns being sadly scarce with
him, poor fellow!
He instituted inquiries, and learnt that Miss Geare belonged to a
good family, and was well-off, but somewhat "queer." In early youth
she was engaged to an officer, who was killed at Delhi, and had
become gradually more and more eccentric, until now she only lived
for her dogs and cats. Miss Pepper, it was added, tyrannised over her
shamefully, as though she were the mistress and Miss Geare the
companion.
The old lady was warm-hearted, though rather fickle, and, having
taken a fancy to Harold, contrived to secure him several fresh and
welcome patients. Miss Geare herself was far from strong, and
afforded a legitimate exercise for Harold's skill, which salved his
conscience in the matter of Bijou. But Miss Pepper remained, from
first to last, distinctly hostile.
[END OF CHAPTER SIX.]](https://image.slidesharecdn.com/1225731-250609232800-dd282e0a/85/Web-Engineering-A-Practioners-Approach-1st-Edition-Roger-Pressman-75-320.jpg)
Web Engineering A Practioners Approach 1st Edition Roger Pressman
- 1. Web Engineering A Practioners Approach 1st Edition Roger Pressman download https://ebookbell.com/product/web-engineering-a-practioners- approach-1st-edition-roger-pressman-2451462 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Web Engineering 11th International Conference Icwe 2011 Paphos Cyprus June 2024 2011 1st Edition Stefano Ceri https://ebookbell.com/product/web-engineering-11th-international- conference-icwe-2011-paphos-cyprus-june-2024-2011-1st-edition-stefano- ceri-2449948 Web Engineering 11th International Conference Icwe 2011 Paphos Cyprus June 2024 2011 1st Edition Stefano Ceri https://ebookbell.com/product/web-engineering-11th-international- conference-icwe-2011-paphos-cyprus-june-2024-2011-1st-edition-stefano- ceri-4143940 Philosophical Engineering Toward A Philosophy Of The Web Harry Halpin Alexandre Monnin https://ebookbell.com/product/philosophical-engineering-toward-a- philosophy-of-the-web-harry-halpin-alexandre-monnin-4699926 Webbased Engineering Education Critical Design And Effective Tools First Donna L Russell https://ebookbell.com/product/webbased-engineering-education-critical- design-and-effective-tools-first-donna-l-russell-2391000
- 3. Web Information Systems Engineering Wise 2009 10th International Conference Pozna Poland October 57 2009 Proceedings 1st Edition Richard A Demillo Auth https://ebookbell.com/product/web-information-systems-engineering- wise-2009-10th-international-conference-pozna-poland- october-57-2009-proceedings-1st-edition-richard-a-demillo-auth-2533752 Web Information Systems Engineering Wise 2009 10th International Conference Pozna Poland October 57 2009 Proceedings 1st Edition Richard A Demillo Auth https://ebookbell.com/product/web-information-systems-engineering- wise-2009-10th-international-conference-pozna-poland- october-57-2009-proceedings-1st-edition-richard-a-demillo-auth-4143960 Web Information Systems Wise 2006 7th International Conference On Web Information Systems Engineering Wuhan China October 2326 2006 Proceedings 1st Edition M Tamer Zsu Auth https://ebookbell.com/product/web-information-systems-wise-2006-7th- international-conference-on-web-information-systems-engineering-wuhan- china-october-2326-2006-proceedings-1st-edition-m-tamer-zsu- auth-4268234 Web Application Design And Implementation Apache 2 Php5 Mysql Javascript And Linux Unix Quantitative Software Engineering Series 1st Steven A Gabarr https://ebookbell.com/product/web-application-design-and- implementation-apache-2-php5-mysql-javascript-and-linux-unix- quantitative-software-engineering-series-1st-steven-a-gabarr-2495740 Ontology Engineering With Ontology Design Patterns Foundations And Applications Studies On The Semantic Web P Hitzler https://ebookbell.com/product/ontology-engineering-with-ontology- design-patterns-foundations-and-applications-studies-on-the-semantic- web-p-hitzler-51881534
- 6. Web Engineering A P R A C T I T I O N E R ’ S A P P R O A C H Roger S. Pressman, R.S. Pressman and Associates, Inc. Boca Raton, Florida, USA David Lowe, University of Technology, Sydney Australia pre23291_ch00_fm.indd i pre23291_ch00_fm.indd i 1/2/08 3:43:02 PM 1/2/08 3:43:02 PM
- 7. WEB ENGINEERING: A PRACTITIONER’S APPROACH Published by McGraw-Hill, a business unit of The McGraw-Hill Companies, Inc., 1221 Avenue of the Americas, New York, NY 10020. Copyright © 2009 by The McGraw-Hill Companies, Inc. All rights reserved. No part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval system, without the prior written consent of The McGraw- Hill Companies, Inc., including, but not limited to, in any network or other electronic storage or transmission, or broadcast for distance learning. Some ancillaries, including electronic and print components, may not be available to customers outside the United States. This book is printed on acid-free paper. 1 2 3 4 5 6 7 8 9 0 DOC/DOC 0 9 8 ISBN 978–0–07–352329–3 MHID 0–07–352329–1 Global Publisher: Raghothaman Srinivasan Director of Development: Kristine Tibbetts Freelance Developmental Services: Melinda Bilecki Senior Project Manager: Kay J. Brimeyer Senior Production Supervisor: Kara Kudronowicz Designer: John Albert Joran Cover Illustration: John Albert Joran Senior Photo Research Coordinator: John C. Leland Compositor: Newgen Typeface: 8.5/13 Leawood Book Printer: R. R. Donnelley Crawfordsville, IN Library of Congress Cataloging-in-Publication Data Pressman, Roger S. Web engineering : a practitioner’s approach / Roger S. Pressman, David Lowe. — 1st ed. p. cm. Includes index. Includes bibliographies and index. ISBN 978–0–07–352329–3 — ISBN 0–07–352329–1 (hard copy : alk. paper) 1. Web services. 2. Web site development. 3. Software engineering. I. Lowe, David. II. Title. TK5105.88813.P72 2009 006.7⬘6—dc22 2007029783 www.mhhe.com pre23291_ch00_fm.indd ii pre23291_ch00_fm.indd ii 1/2/08 3:43:04 PM 1/2/08 3:43:04 PM
- 8. iii CHAPTER 1 Web-Based Systems 1 The Web 1 Web Applications 2 Let’s Introduce a Case Study 3 Are WebApps Really Computer Software? 4 Are the Attributes of WebApps Different from the Attributes of Conventional Software? 4 What Categories Are Encountered as a WebApp Evolves? 7 WebApps—A Philosophical View 10 CHAPTER 2 Web Engineering 12 What Is Web Engineering? 12 What Is Meant by Agile? 12 What Is a WebE Framework? 13 What Principles Should You Follow as You Adapt the Framework? 15 Is There Any Merit in an Old-School Approach? 16 The Components of Web Engineering 16 How Does Software Engineering Come into Play? 17 Why Is WebE Process Agility So Important? 18 What WebE Methods Reside within the Process Framework? 19 Isn’t Web Engineering All about Tools and Technology? 19 Web Engineering Best Practices 21 Where We’ve Been . . . Where We’re Going 23 CHAPTER 3 A Web Engineering Process 24 Defining the Framework 24 Incremental Process Flow 27 How Are Framework Activities Conducted? 28 How Is the Framework Refined? 30 Generic Actions and Tasks for the WebE Framework 32 How Should the Communication Activity Be Refined? 32 What Tasks Are Required to Develop an Increment Plan? 33 What Is Modeling? 35 What Analysis Modeling Tasks Can Be Applied? 35 What Are the Elements of a Design Model? 37 What Design Modeling Tasks Can Be Applied? 38 What Construction Tasks Should Be Applied? 40 How Is a WebApp Increment Deployed? 41 Umbrella Activities 42 How Should a WebE Team Manage Change? 42 How Is the Quality of an Increment Ensured? 43 How Is Risk Managed? 43 How Should the Work Be Managed? 44 Where We’ve Been . . . Where We’re Going 44 Table of Contents pre23291_ch00_fm.indd iii pre23291_ch00_fm.indd iii 1/2/08 3:43:05 PM 1/2/08 3:43:05 PM
- 9. iv CHAPTER 4 Communication 46 The Communication Activity 46 Formulation 47 Who Should We Communicate With? 48 What Techniques Can You Use for Communication? 48 Won’t There Be Different Viewpoints? 49 What Questions Should We Ask? 49 How Do We Encourage Collaboration? 51 Elicitation 53 What Happens Before an Elicitation Session? 53 How Do Stakeholders Prepare? 54 What Tasks Are Performed During an Elicitation Session? 55 What Are the User Categories for the WebApp? 56 How Are Content and Functional Requirements Identified? 57 How Are Constraints and Performance Issues Isolated? 58 What Are Usage Scenarios? 58 What Are Use Cases? 60 How Is a Use Case Created? 60 Identifying WebApp Increments 65 Negotiation 67 Where We’ve Been . . . Where We’re Going 68 CHAPTER 5 Planning 70 Understanding Scope 70 What Communication Work Products Are Relevant? 71 What if Further Details Are Required to Understand the Increment? 71 What if Gaps Still Exist in Your Understanding? 73 Refining Framework Activities 73 What Actions and Tasks Are Required? 74 What Work Products Will Be Produced? 76 What Is the Appropriate Way to Assess Quality? 77 How Should Change Be Managed? 78 Building a WebE Team 79 How Do We Recognize a “Good” WebE Team? 79 Why Don’t Teams Jell and What Can Be Done to Help? 80 Can a WebE Team Manage Itself? 81 How Do We Build a Successful Team? 82 What Are the Characteristics of a Good Team Leader? 83 Managing Risk 84 How Do We Identify Risks? 84 How Do We Evaluate Risks? 85 How Do We Develop Contingency Plans? 86 Developing a Schedule 88 What Is Macroscopic Scheduling? 88 What Is Increment Scheduling? 89 How Do We Estimate Effort and Time? 91 How Do We Represent Task Interdependencies? 93 Table of Contents pre23291_ch00_fm.indd iv pre23291_ch00_fm.indd iv 1/2/08 3:43:06 PM 1/2/08 3:43:06 PM
- 10. v Managing Quality 94 What Quality Assurance Mechanisms Can the Team Use? 95 What Are the Mechanics of a Pair Walkthrough? 95 What Are the Mechanics of a Team Walkthrough? 96 Do Criteria for Quality Exist for WebApps? 97 Managing Change 98 How Should Criticality and Impact of a Change Be Assessed? 99 When Do We Delay Making the Change? 99 Should Changes Be Made to All Related Work Products? 102 Tracking the Project 103 Are There Any Macroscopic Indicators of Progress Problems? 103 What Criteria Are Used to Track Progress? 104 Outsourcing WebE Work 104 How Do We Initiate an Outsourced Project? 105 How Do We Select Candidate Outsourcing Vendors? 106 How Can We Assess the Validity of Price Quotes and the Reliability of Estimates? 106 What Level of Project Management Will Be Needed? 106 How Do We Assess the Schedule and Manage Scope? 107 Where We’ve Been . . . Where We’re Going 107 CHAPTER 6 The Modeling Activity 109 Modeling as a Concept 110 How Do We Judge the Usefulness of a Model? 110 Can Models Be Used to Understand Business Constraints? 111 The Models We Create 112 What Does the Process Tell Us About Modeling? 113 What Does the WebApp Tell Us About Modeling? 113 Modeling Frameworks 114 Is There a Modeling Framework for the Web? 115 How Does Modeling Relate to the WebE Process? 116 Modeling Languages 119 What Capabilities Should Exist to Model Functionality? 120 What Capabilities Should Exist to Model Information Content? 121 What Generic Capabilities Should Exist in a Modeling Language? 122 Existing Modeling Approaches 124 Where We’ve Been . . . Where We’re Going 126 CHAPTER 7 Analysis Modeling for WebApps 129 Understanding Analysis in the Context of WebE 129 How Much Analysis Is Enough? 130 Can We Analyze Using a Prototype? 130 Is Analysis Distinct from Design? 132 Analysis Modeling for WebApps 133 What Are the Inputs to Analysis Modeling? 133 Table of Contents pre23291_ch00_fm.indd v pre23291_ch00_fm.indd v 1/2/08 3:43:06 PM 1/2/08 3:43:06 PM
- 11. vi What Are the Outputs from Analysis? 135 What Analysis Tasks Can and Should We Carry Out? 135 What Tools Can We Use to Help Us Model? 136 How Do We Decide Whether Modeling Is Necessary and Which Approach Is Best? 136 Understanding the Users 138 Why Is It Necessary to Revisit the User Hierarchy? 139 Do We Apply Usage Scenarios As Is? 141 The Content Model 144 What Are the Structural Elements of the Content Model? 144 What Is an Information Exchange and How Is It Represented? 145 How Are Content Objects Defined? 146 Is There a Simple Way to Depict Content Relationships and Content Hierarchy? 150 How Do We Select and Represent Analysis Classes for WebApps? 151 The Interaction Model 152 Where Do Use Cases Come into Play? 152 What Are Sequence Diagrams and When Should They Be Developed? 153 How Do State Diagrams Represent the Behavior of a WebApp? 154 Do We Really Need Use Cases, Sequence Diagrams, and State Diagrams to Fully Describe the Interaction Model? 154 Why Is It a Good Idea to Build an Interface Prototype? 155 The Functional Model 156 The Configuration Model 158 Relationship-Navigation Analysis 159 How Do We Establish Relationships Between Content Objects and Functionality? 160 How Do We Analyze Navigational Requirements? 161 Where We’ve Been . . . Where We’re Going 163 CHAPTER 8 WebApp Design 165 Design for WebApps 165 What Does a WebApp Designer Need to Know? 166 What Is Logical Design? 167 What Is Physical Design? 167 What Information Is Created as a Consequence of Design? 168 Design Goals 168 Design and WebApp Quality 171 How Do Users Perceive Quality? 171 Is There a User-Centric Model for Assessing Design Quality? 172 What Is a Quality Framework? 175 Is There a Way to Assess Content Quality? 178 Is There a Single Quality Checklist I Can Use? 178 The Design Process 180 What Are the Elements of WebApp Design? 180 Table of Contents pre23291_ch00_fm.indd vi pre23291_ch00_fm.indd vi 1/2/08 3:43:06 PM 1/2/08 3:43:06 PM
- 12. vii What Are the Characteristics of the Design Process? 183 What Does an Incremental WebE Process Imply for the Design Activity? 184 Initial Design of the Conceptual Architecture 185 Initial Design of the Technical Architecture 188 Where We’ve Been . . . Where We’re Going 190 CHAPTER 9 Interaction Design 193 Interface Design Principles and Guidelines 194 What Principles Do We Apply to Design Effective Interfaces? 194 What About Some Pragmatic Design Guidelines? 200 Interface Design Workflow 200 Interface Design Preliminaries 202 How Do We Understand the Characteristics of WebApp Users? 203 How Do We Elaborate the Content Objects That Are Identified? 204 What Tasks Do the Users Perform? 206 How Do We Elaborate the Tasks That Are Identified? 208 How Do We Design for Different Users with Different Roles? 209 How Is Content Integrated into the Interface Description? 211 Interface Design Steps 212 How Are Interface Objects and Actions Translated into a Layout? 212 What About the Design of Navigation Mechanisms for the Interface? 215 Why Is Interface Consistency So Important? 218 Aesthetic Design 218 How Do We Create an Aesthetically Pleasing Layout? 219 What Leads to an Effective Graphic Design? 221 Usability 222 Design Issues 223 What Factors Affect Response Time and What Can We Do to Improve It? 223 How Should We Design “Help” Facilities? 224 How Should the Interface Handle Errors? 225 What Is “Accessibility” and How Does It Apply to Interface Design? 226 What Is “Internationalization” and How Does It Apply to WebApps? 227 Where We’ve Been . . . Where We’re Going 228 CHAPTER 10 Information Design 230 Information Architecture 231 What Is an Information Architecture? 231 What Are the Elements of an Information Architecture? 233 Table of Contents pre23291_ch00_fm.indd vii pre23291_ch00_fm.indd vii 1/2/08 3:43:06 PM 1/2/08 3:43:06 PM
- 13. viii What Are the Characteristics of a Good Information Architecture? 233 How Do We Develop an Information Architecture? 236 Organizing Content 237 Structuring the Information Space 238 What Information Structures Are Possible? 239 What Makes a Good Structure? 242 Blueprints: Adding Detail to a Structure 245 What Form Does a Blueprint Take? 245 Accessing Information 247 How Do We Ensure That the User Understands the Context and Doesn’t Get Lost? 247 How Do We Help the User Move Through the Information Structure? 249 What Guidelines Are Available for Implementing Searching Mechanisms? 250 Can Searching Mechanisms Lead to Problems? 252 Wireframe Models 252 Navigation Design: Creating the Detailed Structure 254 How Have Information Design and Navigation Design Models Evolved? 254 How Is the RMM Model Used for Navigation Design? 256 How Can WebML Be Used to Create a Navigation Design? 259 Is It Possible to Create Models That Link Content and Functionality? 259 Does the Structure of the Web Itself Have an Impact? 262 Summarizing the Design Process 262 Where We’ve Been . . . Where We’re Going 265 CHAPTER 11 Functional Design 268 WebApp Functionality 268 The Nature of WebApp Functionality 269 What Are Typical Examples of Functionality? 270 Can Functionality Be Categorized? 270 Is It Always Possible to Distinguish Between Information and Function? 272 Functional Design in the Design Process 274 What Are the Elements of a Functional Design Process? 274 How Much Functional Design Is Enough? 276 How Would Initial Functional Design Be Conducted for SafeHomeAssured.com? 277 Functional Architecture 279 What Does a Functional Architecture Look Like? 280 How Do We Develop the Functional Architecture? 280 What About Functionality for Exception Handling? 282 Can Architectural Patterns Be Used During Functional Design? 284 Table of Contents pre23291_ch00_fm.indd viii pre23291_ch00_fm.indd viii 1/2/08 3:43:07 PM 1/2/08 3:43:07 PM
- 14. ix Detailed Functional Design 286 How Can WAE Modeling Be Used for Detailed Design? 286 Why Is WebML Appropriate for Workflow Modeling? 287 State Modeling 291 Where We’ve Been . . . Where We’re Going 294 CHAPTER 12 Construction and Deployment 296 Construction and Deployment within the WebE Process 297 What Is the Interplay Between Construction and Deployment? 297 What Role Do Deployment Environments Play? 299 Construction 302 Is There a Generic Set of Construction Tasks? 303 What Is Refactoring and How Should It Be Applied? 303 Construction Principles and Concepts 305 Deployment 308 Is There a Generic Set of Deployment Tasks? 308 What Deployment Principles Should Guide the WebE Team? 309 How Are Version Control and CMS Used? 311 Construction and the Use of Components 312 What Is a Generic Component? 313 How Is an Object-Oriented Component Defined? 313 How Is a Conventional Component Defined? 315 What Are the Characteristics of a “Good” Component? 316 Component-Level Design Guidelines 318 Component Design Steps 320 Where We’ve Been . . . Where We’re Going 323 CHAPTER 13 Design Patterns 326 Patterns: Understanding the Concept 326 What Exactly Is a Pattern? 327 What Does a Pattern Look Like? 328 WebApp Patterns: Design Focus and Granularity 329 How Is Design Focus Used to Identify Patterns? 329 Why Is Granularity an Important Characteristic of a Pattern? 330 Pattern Repositories 331 What Is a Patterns Repository? 331 What Patterns Sources Are Available for Web Engineers? 331 Can a WebE Team Create Its Own Set of Patterns? 332 How Do We Find and Use Patterns? 334 Example Patterns 336 Is It Possible to Define Patterns That Address Problems at the Business Level? 336 Since Interaction Is Pervasive, There Must Be Many Interaction Patterns. True? 336 What Navigation Patterns Are Available? 341 Where Do Content and Presentation Patterns Fit In? 344 Where We’ve Been . . . Where We’re Going 347 Table of Contents pre23291_ch00_fm.indd ix pre23291_ch00_fm.indd ix 1/2/08 3:43:07 PM 1/2/08 3:43:07 PM
- 15. x CHAPTER 14 Technologies and Tools 348 General Issues 348 How Does Separation of Concerns Impact Tools and Technologies? 349 Which Technology—Open Source or Proprietary? 350 What Is the Impact of Application Categories on WebE Technology? 351 Implementation Tools and Technologies 352 What Are Application Frameworks? 353 How Are Content Management Systems and Version Control Technologies Applied? 354 What If a Search Capability Must Be Provided with Our WebApp? 354 Development Tools and Technologies 355 Can I Acquire Tools That Will Help Me with the Modeling Activity? 355 Are There Testing Tools That Focus Specifically on WebApps? 356 Are There Tools That Can Assist with the Management of the WebE Process? 357 Where We’ve Been . . . Where We’re Going 358 CHAPTER 15 Testing WebApps 359 Testing Concepts 359 What Are the “Dimensions” of Quality? 360 What Types of Errors Occur within a WebApp Environment? 361 What Testing Strategy Should We Apply? 361 How Much Test Planning Is Necessary? 362 The Testing Process—An Overview 363 Content Testing 367 What Are the Objectives of Content Testing? 367 How Is Database Testing Used to Validate Content? 368 User Interface Testing 370 Is There a Viable Interface Testing Strategy? 371 How Do We Test Specific Interface Mechanisms? 371 How Do We Test Interface Semantics? 374 Usability Testing 375 Compatibility Testing 378 Component-Level Testing 379 Navigation Testing 381 How Do We Test Navigation Syntax? 381 How Do We Test Navigation Semantics? 382 Configuration Testing 384 How Do We Test the Server Side? 385 How Do We Test the Client Side? 386 Security and Performance Testing 386 Table of Contents pre23291_ch00_fm.indd x pre23291_ch00_fm.indd x 1/2/08 3:43:07 PM 1/2/08 3:43:07 PM
- 16. xi How Do We Determine if the WebApp Is Secure? 387 How Should We Test WebApp Performance? 389 What Are the Objectives of Performance Testing? 390 How Does Load Testing Assess Performance? 390 How Does Stress Testing Assess Performance? 391 Where We’ve Been . . . Where We’re Going 396 CHAPTER 16 Change and Content Management 397 Change 397 What Are the Attributes of a “Change”? 398 Why Are Changes Requested? 398 What Elements of the WebApp Change? 399 Change Management for Web Engineering 399 Why Do We Need Change Management? 400 What Issues Should We Consider? 400 What Is the Basic Change Management Activity? 402 How Should We Identify the Objects That Will Change? 402 How Should We Control a Change That Is About to Be Made? 403 How Do We Manage Different Versions of the WebApp or Its Components? 406 How Can a WebE Team Ensure That a Change Has Been Properly Implemented? 407 How Do We Let Stakeholders Know What Changes Have Been Made? 407 Content Management 408 How Is a Content Management System Used? 408 What Are the Major Elements of a CMS? 409 Criteria for Implementing a CMS 412 How Does Volume Affect Content Management? 413 Does the Population of Content Creators Have an Effect on CMS? 414 How Does the Change Volume Affect the Formality of Change Management? 415 How Does Publication Volume Affect Content Management Formality? 415 Where We’ve Been . . . Where We’re Going 419 CHAPTER 17 Future Directions 419 The Changing Nature of the Web and WebApps 419 How Will Delivery of Web-Based Content and Functionality Change? 420 How Will WebApps Change? 420 What Will Web Engineers Have to Do to Accommodate These Changes? 421 Can the Web Serve as a Platform for Application Software? 422 Table of Contents pre23291_ch00_fm.indd xi pre23291_ch00_fm.indd xi 1/2/08 3:43:07 PM 1/2/08 3:43:07 PM
- 17. xii Can the Future Web Be an OS? 423 How Will the “Semantic Web” Change Things? 424 Evolving Web Technologies and Web 2.0 425 What Is Web 2.0? 425 What Technologies Support Web 2.0? 427 What Are Some Key Issues That Should Be Considered as Technology Evolves? 431 What’s Next for Web 2.0? 432 One View of the Future 433 The Changing Nature of Web Engineering 435 Table of Contents pre23291_ch00_fm.indd xii pre23291_ch00_fm.indd xii 1/2/08 3:43:08 PM 1/2/08 3:43:08 PM
- 18. xiii As we began to plan this book, we worried that it would become lost in the hundreds—no, thousands—of volumes that have been written on “Web de- sign,” HTML, Java, XML, or any of the myriad technologies that must be understood to build successful Web-based systems and applications (WebApps). To our sur- prise, we found that one crucial topic—the process through which each of the other technologies is applied—has received relatively little coverage. We call the process Web engineering, and we believe people who apply it have a higher likelihood of building WebApps that satisfy users’ needs and provide real benefit to their clients’ businesses or organizations. It has become a cliché to state that WebApps can be pivotal to the success of virtually all businesses and organizations. And yet, many WebApps continue to be built in an ad hoc manner with little regard to the fundamental principles of prob- lem analysis, effective design, solid testing, and change management. As a conse- quence, many WebApps fail to meet the needs of their users and the objectives of the business that has commissioned them. Today, we’re making the transition from an old-school approach to Web engi- neering in order to meet the challenges posed by the next generation of Web-based systems and applications. The industry is moving toward a more pragmatic Web engineering process—one that exhibits agility and adaptability. At the same time, the process must deliver the integrity of a disciplined approach. Web Engineering: A Practitioner’s Approach has been written to provide you with a solid understanding of a pragmatic process for engineering Web-based systems and applications. The content is presented in an informal, conversational style, us- ing a question-and-answer format to mentor the reader in this new engineering discipline. Throughout the book, we emphasize an agile process and simple, practical methods that have been proven in industry application. At the same time, we have purposely deemphasized our treatment of specific Web-based tools and technolo- gies. This is not because we think they are unimportant, but because there are literally thousands of books, papers, and Web-based resources that address them and surprisingly few that consider Web engineering issues in a cohesive manner. For that reason, our focus is unapologetically on Web engineering. Our intent is to provide a book that can be used by industry practitioners and by students at the undergraduate or first-year graduate level. The Web engineering process emphasizes an agile approach and presents sim- ple, yet effective methods for gathering and analyzing problem requirements, de- signing an effective solution, and then building and testing a high-quality WebApp. Preface pre23291_ch00_fm.indd xiii pre23291_ch00_fm.indd xiii 1/2/08 3:43:08 PM 1/2/08 3:43:08 PM
- 19. xiv But the process is not just about technology. We also present proven techniques for project management, change and content management, and quality assurance. Throughout the book, we present a case study designed to provide examples of the methods and techniques we present. A website, www.SafeHomeAssured.com, complements the case study with additional in-depth detail, as well as providing extra supporting information. Our work on this book has been facilitated by many print and Web-based re- sources that discuss principles and techniques for building high-quality WebApps. Our thanks to the authors of each source referenced within these pages and to hundreds of other colleagues and authors who have shaped our thinking over the years. Special thanks also go to Didar Zowghi, Norazlin Yusop, Xiaoying Kong, and Rachatrin Tongrungrojana. Throughout this book, we have used text excerpts, selected figures, and the SafeHome case study from Roger Pressman’s Software Engineering: A Practitioner’s Approach (sixth edition). In some cases, we have used these materials as is, but in many others, we have adapted them to meet the special needs of Web engineers. In every case, these materials are used with permission. We each have families of four and want to express special thanks for their sup- port during this endeavor. Our wonderful wives—Barbara and Catherine—have graciously tolerated the many hours of writing, revision, and travel that come with the production of a book. Roger’s sons—Mathew and Michael—are grown, have businesses of their own, and use the Internet and Web every day. David’s sons— Oliver and Dominic—are young, have their whole future ahead of them, and will surely spend much of their professional lives navigating the Web of tomorrow. We hope that the ideas presented in this book will make their journey easier. Roger Pressman Boca Raton, Florida, USA David Lowe Sydney, Australia Preface pre23291_ch00_fm.indd xiv pre23291_ch00_fm.indd xiv 1/2/08 3:43:08 PM 1/2/08 3:43:08 PM
- 20. 1 1 Let’s go back in time and revisit the early decades of computer soft- ware development. During the 1950s and 1960s few people appreci- ated the importance of computer-based systems, and virtually no one foresaw the global impact that computer hardware and software would have on every aspect of society in the late twentieth and early twenty- first centuries. Most people who worked with computers during the early days stumbled into the business, creating computer programs using a combination of informality, urgency, intuition, and art. When things worked out well, this approach lead to important advances in computing. But things didn’t always work out well. Computer-based systems often failed to do what they were supposed to do; were delivered late or not at all; and were difficult and sometimes impossible to correct, adapt, and enhance in any reasonable time frame. The old-school approach was, regrettably, a hit-or-miss proposition. But old-school thinking established a culture that quickly became entrenched. Informality, urgency, intuition, and art were the driving forces behind the activities of most computer-based system developers. After all, informality leads to an easy work environment—one in which you can do your own thing. Urgency leads to action and rapid decision making. Intuition is an intangible quality that enables you to “feel” your way through complex situations. And art leads to aesthetic form and function—to something that pleases those who encounter it. And what, you might ask, is wrong with any of that? As we change our focus from the past to the present, you’ll find that the answer to this question has much to do with Web engineering, the topic that we’ll discuss throughout this book. The Web Today, we’re living in the formative years of the Internet era. So much has already been said about this exciting time that it’s impossible to dis- cuss the impact of the Internet and the World Wide Web without lapsing into a cliché-ridden dialogue. You already know the Web is big, very big. But we don’t mean “big” in the typical sense (e.g., number of Web pages and sites, number of users, amount of information flowing across the network), although the size of the Web and its projected growth rate are staggering. We mean big in a societal and cultural sense. WEB-BASED SYSTEMS 1 C H A P T E R pre23291_ch01.indd 1 pre23291_ch01.indd 1 1/2/08 3:43:25 PM 1/2/08 3:43:25 PM
- 21. CHAPTER 1 WEB-BASED SYSTEMS 2 The Web has become an indispensable technology for business, commerce, communication, education, engineering, entertainment, finance, government, in- dustry, media, medicine, politics, science, and transportation—to name just a few areas that impact your life. But being an “indispensable technology” only scratches the surface of the Web’s impact on each of us. It has changed the ways in which we buy products (e-commerce), meet people (online dating), understand the world (portals), acquire our news (online media), voice our opinions (blogs), entertain ourselves (everything from music downloads to online casinos), and go to school (online learning). All of these impacts have one thing in common—they need a delivery vehicle that takes raw information associated with the area of interest; structures it in a way that is meaningful; builds a packaged presentation that is organized, aesthetic, ergonomic, and interactive (where required); and delivers it to your Web browser in a manner that initiates a conversation. The conversation between you and a Web application can be passive or active. In a passive conversation, you select the information that is to be presented, but have no direct control over its volume, type, or structure. In an active conversation, you provide input so that the information that is presented is customized to meet your needs specifically. The vehicle that acquires information, structures it, builds a packaged pre- sentation, and delivers it is called a Web application (WebApp). When a WebApp is combined with client and server hardware, operating systems, network software, and browsers, a Web-based system emerges. Web Applications In the early days of the World Wide Web (circa 1990 to 1995), “websites” consisted of little more than a set of linked hypertext files that presented information using text and limited graphics. As time passed, Hypertext Markup Language (HTML) was augmented by development tools and technologies [e.g., Extensible Markup Language (XML), Java] that enabled Web engineers to provide both client-side and server-side computing capability along with content. Web-based systems and ap- plications1 were born. Today, WebApps have evolved into sophisticated computing tools that not only provide stand-alone functionality to the end user, but also have been integrated with corporate and governmental databases and applications. 1 In the context of this book, the term Web application (WebApp) encompasses everything from a simple Web page that might help a consumer compute an automobile lease payment to a comprehensive website that provides complete travel services for business people and vaca- tioners. Included within this category are complete websites, specialized functionality within websites, and information-processing applications that reside on the Internet or on an Intranet or Extranet. pre23291_ch01.indd 2 pre23291_ch01.indd 2 1/2/08 3:43:26 PM 1/2/08 3:43:26 PM
- 22. CHAPTER 1 WEB-BASED SYSTEMS 3 Let’s Introduce a Case Study You’ve been approached by CPI Corporation, a (fictional) company that builds, mar- kets, sells, and monitors security systems for homes and small businesses. CPI has no Web presence and wants to roll out a “significant” website that will coin- cide with the introduction of a new line of security sensors and a set of radically new Web-based services. They want your help in the development of the WebApp, which is called SafeHomeAssured.com, and at the same time for you to assist them as they create new Web services that will increase their market share. You have been asked to attend a meeting in which basic ideas are discussed. During the meeting you learn that CPI has engineered a compact, wireless sensor- controller that will become the core element in a new line of commercial and resi- dential security systems that it intends to call SafeHome. A snippet of conversation from the meeting is depicted in the sidebar. A Project Begins The scene: Meeting room at CPI Corporation, a (fictional) company that makes consumer products for home and commer- cial use The players: A senior business manager; a product development manager; a marketing manager; an engineering manager; and you, the Web engineering expert The conversation: Business manager (to product manager): Okay, what’s this I hear about your folks developing a what? A generic universal wireless box? Product manager: It’s pretty cool . . . about the size of a small matchbook . . . we can attach it to sen- sors of all kinds, a digital camera, just about anything using an IEEE wireless protocol. It allows us to access the device without wires. We think it’ll lead to a whole new generation of products. Business manager (looking at the marketing manager): You agree? Marketing manager: I do. In fact, with sales as flat as they’ve been this year, we need something new. We’ve been doing a little market research, and we think we’ve got a line of products and services that could be big. Business manager: How big . . . bottom line big? Marketing manager: It’s a whole new generation of what we call “home management products.” We call ’em SafeHome. They use the new wireless inter- face, provide homeowners or small-business people with a system that’s controlled by their PC via the Internet—home security, home surveillance, appliance and device control—you know, turn down the home air conditioner while you’re driving home, that sort of thing. We’re also thinking about video monitoring and control within a house or business. Just as important, we intend to vertically integrate the product into our monitoring services, allowing customers to access their account via the Web and determine things like when the system is armed or disarmed, what “events” have occurred over a defined time period . . . things like that. We also intend to do most of our maintenance diagnostics via the Web. Product manager: Engineering’s done a techni- cal feasibility study of these ideas. They’re doable at relatively low cost. Most hardware is off-the-shelf. Soft- ware for the Web is an issue, but it’s nothing that we can’t get done. We already registered a domain . . . SafeHomeAssured.com. [All CPI managers look directly at you and smile.] Business manager: Interesting. Now, I asked about the bottom line. (continued) SAFEHOME pre23291_ch01.indd 3 pre23291_ch01.indd 3 1/2/08 3:43:27 PM 1/2/08 3:43:27 PM
- 23. CHAPTER 1 WEB-BASED SYSTEMS 4 And so, a project begins. You’ll notice that there are few details at this stage. Many things need to be defined, specified, and then implemented. The internal percep- tion of the product will change, along with the Web-based system that will support it. But that really doesn’t matter at this early stage. SafeHome has the support of senior management (who see significant profit potential), and you have an oppor- tunity to be one of the team that will get the job done. We’ll return to SafeHome and the SafeHomeAssured.com WebApp repeatedly throughout this book, using the project as a case study for describing many as- pects of Web engineering. But for now, let’s return to our introductory discussion of WebApps and examine their similarity to conventional computer software. Are WebApps Really Computer Software? There’s really no debate here—WebApps are computer software in the sense that they are a collection of executable instructions and data that provide both in- formation and functionality for end users. The implication, therefore, is that it’s reasonable to expect that we can develop WebApps by heeding some, if not all, of the lessons we’ve learned during the many decades we’ve built conventional computer-based systems. It’s also reasonable to assume that we’ll encounter many, if not all, of the problems (both cultural and technical) that we experienced during the earlier era. But more on all that later in this book. Are the Attributes of WebApps Different from the Attributes of Conventional Software? There is some debate about the correct answer to this question. Some people ar- gue that a WebApp is nothing more than a client-server application with a heavy emphasis on both aesthetic presentation (e.g., layout, graphics, audio and video elements) and functionality and that both WebApps and conventional client-server applications have the same attributes. But others (including us, the authors of this book) think that when considered in their totality, a complete set of WebApp char- acteristics do differentiate Web-based systems from more conventional computer- Marketing manager: PCs have penetrated a huge percentage of all households in the United States. If we could price this thing right, it could be a killer-App. Nobody else has our wireless box . . . it’s propri- etary. We’ll have a 2-year jump on the competition. Revenue? Maybe as much as $30 to $40 million in the second year. Business manager (smiling broadly): Let’s take this to the next level. I’m interested. SAFEHOME (CONTINUED) pre23291_ch01.indd 4 pre23291_ch01.indd 4 1/2/08 3:43:29 PM 1/2/08 3:43:29 PM
- 24. CHAPTER 1 WEB-BASED SYSTEMS 5 based systems. The following attributes are encountered in the vast majority of WebApps. Network intensiveness. Every WebApp resides on a network and must serve the needs of a diverse community of clients. In the case of the Safe- Home Product,2 many of the new features to be implemented by CPI will be initiated, controlled, and/or monitored via the Web. The network will enable communication between client-based features of the SafeHomeAssured.com WebApp and the servers established by CPI. Concurrency. A large number of users may access the WebApp at one time. In many cases, the patterns of usage among end users will vary greatly. In some cases, the actions of one user or one set of users may have an impact on the actions of other users or the information presented to other users. In the case of SafeHomeAssured.com, tens of thousands of homes will be moni- tored concurrently, hundreds or thousands of customers may access the WebApp at any given time, and dozens of service technicians may also be online. Unpredictable load. The number of users of the WebApp may vary by orders of magnitude from day to day. In the case of SafeHomeAssured.com, the number of homes and businesses that are monitored will change slowly. But the WebApp must be capable of handling an indeterminate number of events simultaneously (e.g., burglar alarm, fire detection, carbon monoxide detection). On Monday, 10 events might be reported per hour. On Tuesday, 100 events might be recorded, and on Wednesday (after a region suffers a major power outage) thousands of events may be reported per minute. Performance. If a WebApp user must wait too long (for access, for server- side processing, for client-side formatting and display), he or she may decide to go elsewhere. In the case of SafeHomeAssured.com, performance is critical since human life may be at stake. If the WebApp responds too slowly to an event, litigation may result. Availability. Although an expectation of 100 percent availability is unrea- sonable, users of popular WebApps often demand access on a “24/7/365” basis. In the case of SafeHomeAssured.com, availability of 100 percent is the goal and—given that the system is about home security—the WebApp must be designed to achieve this ideal (or something very close to it). 2 SafeHome is a security system supported by a Web-based system that was introduced earlier in this chapter. It will be used as a running case study throughout this book. pre23291_ch01.indd 5 pre23291_ch01.indd 5 1/2/08 3:43:30 PM 1/2/08 3:43:30 PM
- 25. CHAPTER 1 WEB-BASED SYSTEMS 6 Data driven. The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end user. In ad- dition, WebApps are commonly used to access information that exists on databases that are not an integral part of the Web-based environment (e.g., e-commerce or financial applications). In the case of SafeHomeAssured.com, all of these attributes will be evident. In addition, the WebApp must ac- cess a database that contains information about each customer; the system configuration the customer has; and the monitoring requirements for that system, an event log, and a maintenance log. Content sensitive. The quality and aesthetic nature of content remains an important determinant of the quality of a WebApp. In the case of SafeHomeAssured.com, an important user class for the WebApp will be “civilians,” that is, nontechnical people who demand simple, yet mean- ingful content presentation. Continuous evolution. Unlike conventional application software that evolves over a series of planned, chronologically spaced releases, WebApps evolve continuously. It is not unusual for some WebApps (specifically, their content) to be updated on a minute-by-minute schedule or for content to be independently computed for each request. As we’ll see later in the book, the SafeHomeAssured.com WebApp will evolve as the perception of the system changes over time. The evolution of the WebApp will demand an “incremen- tal” approach to its development. Immediacy. Although immediacy—the compelling need to get software to market quickly—is a characteristic of many application domains, WebApps often exhibit a time-to-market that can be a matter of a few days or weeks.3 Web engineers must use methods for planning, analysis, design, implemen- tation, and testing that have been adapted to the compressed time schedules required for WebApp development. In the case of SafeHomeAssured.com, CPI management is focused on a revenue boost in the short term and signifi- cant revenue in the medium term. When this occurs, the WebApp is needed “yesterday.” Security. Because WebApps are available via network access, it is diffi- cult, if not impossible, to limit the population of end users who may access the application. In order to protect sensitive content and provide secure modes of data transmission, strong security measures must be implemented throughout the infrastructure that supports a WebApp and within the appli- cation itself. In the case of SafeHomeAssured.com, information is flowing into 3 With modern tools, sophisticated Web pages can be produced in only a few hours. pre23291_ch01.indd 6 pre23291_ch01.indd 6 1/2/08 3:43:30 PM 1/2/08 3:43:30 PM
- 26. CHAPTER 1 WEB-BASED SYSTEMS 7 and out of people’s homes and businesses, making the WebApp a perfect target for those with criminal intent. It had better be secure! Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel. When an application has been designed to market or sell products or ideas or provide services that generate revenue, aesthetics may have as much to do with success as technical design. In the case of SafeHomeAssured.com, the multiplicity of content and functions that the WebApp will provide (to be discussed in Chapter 4) demands that their presentation be both simple and elegant. Aesthetics is a key element for the acceptance of the system. What Categories Are Encountered as a WebApp Evolves? You continue your meetings with the folks at CPI, gaining a better understanding of the current perception of SafeHomeAssured.com from the managers who have prod- uct responsibility and the technical people who will be working with you directly. It becomes apparent that the SafeHomeAssured.com WebApp will be fairly significant. There have been no firm commitments as yet, but it appears that the following fea- tures (content and function) will be implemented: • Information about CPI and its products and people • Specifications for all security hardware components, including pictures, technical descriptions, installation instructions, pricing, and other pertinent information • Security system design assistance that enables a customer to specify a living or business space (e.g., rooms, doors, windows) and then get semiautomated layout assistance for a security system • e-Commerce capability that enables a customer to order security hardware and monitoring services. This capability will be coupled to backroom sys- tems that support a customer purchase. • Customer monitoring via the Internet that enables a homeowner or busi- nessperson to use video to monitor a space in real time • Customer account access capability • Customer service access capability including specialized in-house functionality • Technical service staff access capability including specialized in-house functionality In addition, CPI wants to abandon a brick-and-mortar sales strategy (i.e., salespeo- ple, store fronts) and move toward a twenty-first century paradigm. The company wants to sell exclusively via the Web. pre23291_ch01.indd 7 pre23291_ch01.indd 7 1/2/08 3:43:30 PM 1/2/08 3:43:30 PM
- 27. CHAPTER 1 WEB-BASED SYSTEMS 8 But CPI has no meaningful Web presence, not to mention written requirements for what the SafeHomeAssured.com WebApp is to be, and it doesn’t yet have a partic- ularly sophisticated understanding of the true capabilities of the Web. For example, the people at CPI look at you blankly when you mention the possibility of eventu- ally—in a year or two—having an interface to clients’ security systems through a virtual world containing three-dimensional (3D) renditions of their homes (like Second Life4 ). You decide to provide them with a quick example website, if only to get started. The actual SafeHomeAssured.com WebApp will evolve in stages that we’ll call WebApp increments. As the WebApp evolves, it will take on the characteristics of the categories5 that follow: Informational WebApps. You decide to build a home page and a few supplementary pages that describe CPI and its products and services. What you’ve done is to create an informational WebApp—one that contains read- only content with simple navigation and links. Download WebApps. A few weeks later, you begin to add content that describes SafeHome sensors and other security system hardware. CPI pro- vides you with PDF (Portable Document Format) specification files describing each. You add a capability that allows visitors to the SafeHomeAssured.com WebApp to download the product specs. The WebApp now incorporates informational and download capability. Customizable WebApps. As you learn more from CPI stakeholders, it be- comes apparent that you have four kinds of potential end users: homeown- ers, small-business owners, CPI customer service staff, and CPI technical service staff. You want to tailor the content presented at the website to the specific needs of each customer type, using jargon and presenting content that will meet their needs. You do a major overhaul of your initial WebApp and create a new one that is customizable for each user. Interaction WebApps. Traffic increases rapidly, and before long you have hundreds of visitors each day (after all, people worry about effective solu- tions for home and business security). You want to create a feeling of com- munity among your visitors—a place where people can chat, ask and answer questions, provide product testimonials, and the like. You decide to imple- ment an extension to SafeHomeAssured.com that supports a chat room feature. You’ve now provided an interactive component for your WebApp. User Input WebApps. CPI management wants to move away from e-mail and telephone calls requesting quotes for specific security products. You 4 See http://secondlife.com/. 5 The WebApp categories that follow have been adapted from [Dar99]. pre23291_ch01.indd 8 pre23291_ch01.indd 8 1/2/08 3:43:30 PM 1/2/08 3:43:30 PM
- 28. CHAPTER 1 WEB-BASED SYSTEMS 9 implement forms-based input so that every request for a quote is organized in a predictable manner. You still develop the quotes using other automa- tion, but at least you don’t have to transcribe a variety of disparate inputs and sources of information. Transaction-Oriented WebApps. The forms-based input for quotes works well, but CPI management quickly realizes that the entire quotation process can be automated. They provide you with a series of algorithms for computing hardware and monitoring pricing based on forms-based input. The user is now provided with an instant quote based on the input provided via the forms. A transaction between the user and the WebApp occurs. Service-Oriented WebApps. You’re now ready to provide a comprehen- sive design assistance capability. The user inputs a description of a space graphically and is then assisted in the design of a security system for that space. This service can lead directly to sales revenue. In addition, it empha- sizes the overall sophistication of CPI and SafeHome products. Portals. Time passes, and your dedicated hard work pays off with thou- sands of visitors each day. CPI staff members receive hundreds of security- related questions each day. They don’t have the time to answer each. To help solve the problem you begin providing links to appropriate websites that do have answers. Before long, a portion of your site channels users to a wide variety of useful information sources. The SafeHomeAssured.com WebApp now has attributes of a portal. Database Access. Your product line and customer base grow dramatically, and it becomes necessary to build three new databases: (1) all SafeHome products as well as technical specifications, pricing (for customer category), installation guidelines, and delivery and availability information, (2) all customer-related information, and (3) all monitoring related information. These databases can be queried using aspects of the user input elements of the WebApp. Data Warehousing. CPI is rapidly becoming a major international supplier of security products. To meet the needs of many countries, you must tap information about local building regulations, suppliers, installers, and the like. You need to gain access to multiple databases and extract information that will be useful for your customers. You begin to build a large-scale data warehousing component for the SafeHomeAssured.com WebApp. The SafeHomeAssured.com WebApp will evolve through each of these categories. As we move further into the book, we’ll take a much more detailed look at the requirements pre23291_ch01.indd 9 pre23291_ch01.indd 9 1/2/08 3:43:31 PM 1/2/08 3:43:31 PM
- 29. 10 that will lead to the evolution of SafeHomeAssured.com. WebApp attributes and cat- egories are summarized in Figure 1.1. WebApps—A Philosophical View Earlier we noted that the Web is big, both physically and culturally. But its impact goes beyond bigness. It is reasonable to assert that the Web represents a global consciousness—a vast sea of data, information, knowledge, and even wisdom— that includes the collective “thinking” of disparate entities (people, institutions, cultures, and nations). Some elements of the new global consciousness are relatively mundane. We can apply simple data-mining techniques to merge information from seemingly unrelated Web sources, thereby creating a new way of looking at the world (ap- plications of this nature are often referred to as mashups). For example, informa- tion acquired from maps.google.com can be combined with information from the SafeHomeAssured.com database to create a city map that shows the location of every SafeHome-monitored house in a city. Other aspects of global consciousness are intriguing but much more difficult to achieve. For example, it might be possible for advanced search engines to examine the universe of Web sources (e.g., blogs, online media, chat rooms, business data sources, online technical journals, entertainment sites) in an effort to extract trends (for business, entertainment, politics) that could not be discerned from one or two Web sources alone. CPI Corporation could use Web-based data-mining techniques FIGURE 1.1 WebApp attributes and categories. Attributes Categories WebApp Informational Download Customizable Interaction User input Transaction-oriented Service-oriented Portals Database access Data Warehousing Network intensive Concurrent Unpredictable loading Performance sensitive High availability Data driven Content sensitive Continuous evolution Immediacy Security Aesthetics CHAPTER 1 WEB-BASED SYSTEMS pre23291_ch01.indd 10 pre23291_ch01.indd 10 1/2/08 3:43:31 PM 1/2/08 3:43:31 PM
- 30. CHAPTER 1 WEB-BASED SYSTEMS 11 to collect crime-related statistics by neighborhood in cities across the country, then use Web-based demographic data to target households in those neighborhoods that are potential purchasers of SafeHome, and, finally, develop a targeted market- ing campaign that focuses on those households. Today, this Internet sea washes over each of us. We surf (it’s interesting that this term is used) looking for data, information, and knowledge. But we almost never get a glimpse at the consciousness that seethes beneath the surface. As time passes and we move further into the twenty-first century, Web engineers will begin to create systems that will enable all of us to extract data, information, and knowl- edge in novel ways—to do more than skim across the surface. Most of this book is about a philosophy, but one of a more pragmatic kind. In the chapters that follow, we’ll discuss Web engineering—a framework that enables the creation of WebApps that may ultimately guide us along the journey toward a global consciousness. Reference [Dar00] Dart, S., Configuration Management: The Missing Link in Web Engineering, Artech House, 2000. pre23291_ch01.indd 11 pre23291_ch01.indd 11 1/2/08 3:43:31 PM 1/2/08 3:43:31 PM
- 31. 12 12 12 WEB ENGINEERING So, you want to build a WebApp? You could, of course, use the old- school approach that we discussed at the beginning of Chapter 1— crafting a WebApp using a combination of informality, urgency, intuition, and art. If things work out well, you and your colleagues will be heroes and a meaningful WebApp will be born. But things don’t always work out well, particularly if your approach relies solely on informality, urgency, intuition, and art. And when that happens, the “hero” will crash and burn. The WebApp may not do what it was supposed to do; it may be delivered late or not at all; or it may be difficult or impossible to correct, adapt, and enhance in a time frame that is acceptable in the hurry-up world of the Web. You’ll be taking a big risk if you adopt the old-school WebApp devel- opment philosophy. If it’s just about you, go ahead and be a risk taker— roll the dice. We have no problem with that. But it’s rarely just about you. Your customers want a WebApp that will meet their needs, one that will be reliable, extensible, and functional. Your management (if you work for a business, an educational institution, or government) has probably built the existence of the WebApp into a broader business strategy. Your coworkers are relying on the timely delivery of the WebApp to coincide with systems and processes that they are developing. A community of people needs a WebApp that works. They don’t want big risks. There is an alternative to the old-school approach—one that reduces (but does not eliminate) risk and has a higher likelihood of success when industry-quality WebApps are to be built. The alternative is Web engi- neering (WebE). What Is Web Engineering? Let’s answer the question posed in the heading of this section in a suc- cinct manner: Web engineering proposes an agile, yet disciplined frame- work for building industry-quality WebApps. This seems simple enough, but it’s very important that you understand two key words in our answer: agile and framework. What Is Meant by Agile? Web engineers must understand that modern business demands adapta- tion, business strategies and rules change rapidly, management demands near-instantaneous responsiveness (even when such demands are 2 C H A P T E R pre23291_ch02.indd 12 pre23291_ch02.indd 12 1/2/08 3:43:45 PM 1/2/08 3:43:45 PM
- 32. CHAPTER 2 WEB ENGINEERING 13 completely unreasonable), and stakeholders1 keep changing their minds even as they demand rapid delivery. Customers care about a WebApp that’s delivered when they need it, not about the work that goes into creating a deliverable WebApp. With all this in mind, a WebE team must emphasize agility. Ivar Jacobson [Jac02] pro- vides a useful discussion of the concept: An agile team is a nimble team able to appropriately respond to changes. Change is what software development is very much about. Changes in the software being built, changes to the team members, changes because of new technology, changes of all kinds that may have an impact on the product they build or the project that creates the product. Support for changes should be built-in everything we do in software, some- thing we embrace because it is the heart and soul of software. An agile team recog- nizes that software is developed by individuals working in teams and that the skills of these people, their ability to collaborate is at the core for the success of the project. In Jacobson’s view, the pervasiveness of change is the primary driver for agility. Web engineers must be quick on their feet if they are to accommodate the rapid changes that Jacobson describes. What Is a WebE Framework? A framework2 establishes the foundation for a complete Web engineering pro- cess by identifying a small number of framework activities that are applicable to all WebApp projects, regardless of their size or complexity. In addition, the framework encompasses a set of umbrella activities that are applicable across the entire WebE process. Referring to Figure 2.1, each framework activity is populated by a set of Web engineering actions—a collection of related tasks that produces a work product (e.g., design is a WebE action). Each action is populated with individual work tasks that accomplish some part of the work implied by the action. The following WebE activities are part of a generic framework and are appli- cable to the vast majority of WebApp projects: Communication. Involves heavy interaction and collaboration with the customer (and other stakeholders) and encompasses requirements gathering and other related activities. Planning, Establishes an incremental plan3 for the WebE work. It describes the WebE actions that will occur, the technical tasks to be conducted, the 1 A stakeholder is anyone who has a stake in the successful outcome of the project—business managers, end users, Web engineers, support people, and the like. Rob Thomsett jokes that “a stakeholder is a person holding a large and sharp stake . . . If you don’t look after your stake- holders, you know where the stake will end up.” 2 The phrases process, process model, and process framework are also used in this context. 3 An incremental plan assumes that the WebApp is to be delivered in a series of “increments” that provide successively more robust sets of requirements with each delivery. pre23291_ch02.indd 13 pre23291_ch02.indd 13 1/2/08 3:43:46 PM 1/2/08 3:43:46 PM
- 33. 14 risks that are likely, the resources that will be required, the work products to be produced, and a work schedule. Modeling. Encompasses the creation of models that assist the developer and the customer to better understand WebApp requirements and the design that will achieve those requirements. Construction. Combines both the generation of HTML, XML, Java, and similar code with testing that is required to uncover errors in the code. Deployment. Delivers a WebApp increment4 to the customer who evaluates it and provides feedback based on the evaluation. 4 A WebApp increment delivers selected content and functionality to the end user. Later incre- ments expand on the content and functionality delivered until the completed WebApp is deployed. FIGURE 2.1 A WebE process framework. CHAPTER 2 WEB ENGINEERING WebE process Process framework Umbrella activities Framework activity 1 Web engineering action 1.1 Set of tasks Work tasks Work products Quality assurance points Project milestones Web engineering action 1.k Set of tasks Work tasks Work products Quality assurance points Project milestones Work tasks Work products Quality assurance points Project milestones Work tasks Work products Quality assurance points Project milestones ••• ••• Framework activity n Web engineering action n.1 Set of tasks Web engineering action n.m Set of tasks ••• pre23291_ch02.indd 14 pre23291_ch02.indd 14 1/2/08 3:43:47 PM 1/2/08 3:43:47 PM
- 34. CHAPTER 2 WEB ENGINEERING 15 These five generic framework activities can be used during the development of WebApps of all sizes and complexity. The details of the framework can be quite dif- ferent in each case, but the framework activities remain the same. Referring again to Figure 2.1, each Web engineering action is represented by a set of tasks—each a collection of Web engineering work tasks, related work prod- ucts, quality assurance points, and project milestones. The set of tasks that best accommodates the needs of the project and the characteristics of the team is cho- sen. This implies that a Web engineering action (e.g., requirements gathering) can be adapted to the specific needs of the WebApp project and the characteristics of the project team. Umbrella activities (e.g., risk management, quality assurance, content manage- ment) are applied throughout the WebE process and are discussed in detail later in this book. Intelligent application of any framework must recognize that adaptation (to the problem, to the project, to the team, and to the organizational culture) is essential for success. Adaptation affects each of the following framework characteristics: • Overall flow of activities, actions, and tasks and the interdependencies among them • Degree to which work tasks are defined within each framework activity • Degree to which work products are identified and required • Manner in which quality assurance activities are applied • Manner in which project tracking and control activities are applied • Overall degree of detail and rigor with which the process is described • Degree to which customers and other stakeholders are involved with the project • Level of autonomy given to the software project team • Degree to which team organization and roles are prescribed What Principles Should You Follow as You Adapt the Framework? The adapted framework for WebE should emphasize project agility and follow a set of 12 agility principles adopted by the Agile Alliance [Agi03]: • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. pre23291_ch02.indd 15 pre23291_ch02.indd 15 1/2/08 3:43:47 PM 1/2/08 3:43:47 PM
- 35. CHAPTER 2 WEB ENGINEERING 16 • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity—the art of maximizing the amount of work not done—is essential. • The best architectures, requirements, and designs emerge from self- organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Is There Any Merit in an Old-School Approach? It’s reasonable to ask whether informality, urgency, intuition, and art have any role to play in Web engineering. The answer is an unqualified “yes.” But each of these forces should be moderated by a philosophy that works to reduce risk while at the same time improving the likelihood of success. Agility encourages informality and at the same time recognizes that there is a sense of urgency associated with the development of every industry-quality WebApp. Each WebE team should adapt the generic framework to best fit the prob- lem at hand and, at the same time, rely on intuition as well as past experience to guide the manner in which the adaptation occurs. The WebE actions and tasks that are performed as part of any adapted framework adopt defined technical methods (for requirements analysis, design, code generation, and testing). However, these methods will succeed only if the technology (delivered by the methods) is coupled with the art that every skilled Web engineer brings to the work that is performed. The Components of Web Engineering The implication of our discussion earlier in this chapter is that Web engineering encompasses the entire landscape of software engineering practices and process flow but does so in a manner that adapts and distills the process and each practice to the special attributes and characteristics of WebApps. Hopefully, you already have some familiarity with software engineering prac- tices and process flow, but in case you don’t, let’s spend a moment discussing them. pre23291_ch02.indd 16 pre23291_ch02.indd 16 1/2/08 3:43:47 PM 1/2/08 3:43:47 PM
- 36. CHAPTER 2 WEB ENGINEERING 17 How Does Software Engineering Come into Play? In a virtual round table published in IEEE Software [Pre98], Roger staked out a posi- tion that couples Web engineering and software engineering: It seems to me that just about any important product or system is worth engineering. Before you start building it, you’d better understand the problem, design a workable solution, implement it in a solid way, and test it thoroughly. You should probably also control changes to it as you work and have some mechanism for ensuring the end result’s quality. Many Web developers don’t argue with this; they just think their world is really different and that conventional software engineering approaches simply don’t apply. His argument was that software engineering principles, concepts, and methods can be applied to Web development, but their application requires a somewhat dif- ferent approach than their use during the development of conventional software- based systems. Software engineering5 is a philosophy, incorporating a process, a collec- tion of methods, and a tool set, that has been adopted wherever software is built. And yet, software engineering continues to have a public relations problem with at least some (often vocal) software developers. Some developers think that soft- ware engineering is ponderous and slow. They believe that it is about generating documents—lots of documents. They argue that it overburdens a software team with planning and places unfair management restrictions on the team. The prob- lem is: they’re wrong. If software engineering is applied incorrectly, it can be the things that some people worry about, but if it is applied in an agile manner, it can only serve to improve the quality and speed the delivery of each system that is built using it. Software engineering is a layered technology. Referring to Figure 2.2, its foun- dation is an organizational commitment to quality6 —a promise to foster a con- tinuous process improvement culture. It is this culture that ultimately leads to the development of increasingly more effective approaches to software engineering. The process layer is the glue that holds the technology layers together and en- ables rational and timely development of computer software. It forms the basis for management control of software projects and establishes the context in which technical methods are applied, work products (e.g., models and documents) are produced, milestones are established, quality is ensured, and change is properly managed. 5 For a reasonably comprehensive discussion of software engineering, we recommend that you examine Software Engineering: A Practitioner’s Approach [Pre09]. 6 Total quality management, Six Sigma, and ISO 9001 are typical of corporate programs that foster a quality culture. pre23291_ch02.indd 17 pre23291_ch02.indd 17 1/2/08 3:43:48 PM 1/2/08 3:43:48 PM
- 37. 18 Software engineering methods provide the technical how-to’s for building software. Methods encompass a broad array of actions and tasks that include communication, requirements analysis, design modeling, program construction, testing, and support. These methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. Software engineering tools provide automated or semiautomated support for the process and the methods. When tools are integrated so that information cre- ated by one tool can be used by another, an automated environment for the sup- port of software engineering is established. Why Is WebE Process Agility So Important? We have already noted that a WebE process model (we referred to this as a frame- work earlier in this chapter) should be agile. This implies a lean engineering approach that incorporates rapid development cycles. Each cycle results in the deployment of a WebApp increment. Aoyama [Aoy98] describes the motivation for the agile approach in the following manner: The Internet changed software development’s top priority from what to when. Reduced time-to-market has become the competitive edge that leading companies strive for. Thus, reducing the development cycle is now one of software engineering’s most im- portant missions. Even when rapid cycle times dominate development thinking, it is important to recognize that the WebE framework must be defined within a process that: (1) em- braces change, (2) encourages the creativity and independence of development staff and strong interaction with WebApp stakeholders, (3) builds systems using small development teams, and (4) emphasizes incremental development using short development cycles. In Chapter 3 we’ll discuss the details of a process framework that can work well for many WebE projects. For now, you should recognize that agility will be the underlying philosophy for our Web engineering work. But you should also under- stand that an emphasis on agile development in no way mitigates the need for a disciplined engineering approach. FIGURE 2.2 Software engineering layers. Tools Methods Process A quality focus CHAPTER 2 WEB ENGINEERING pre23291_ch02.indd 18 pre23291_ch02.indd 18 1/2/08 3:43:48 PM 1/2/08 3:43:48 PM
- 38. CHAPTER 2 WEB ENGINEERING 19 What WebE Methods Reside within the Process Framework? The WebE methods landscape encompasses a set of technical tasks that enable a Web engineer to understand, characterize, and then build a high-quality WebApp. WebE methods (discussed in detail in Chapters 6 through 15) can be categorized in the following manner: Communication methods. Define the approach used to facilitate com- munication between Web engineers and all other WebApp stakeholders (e.g., end users, business clients, problem domain experts, content designers, team leaders, project managers). Communication techniques are particularly important during requirements gathering and whenever a WebApp incre- ment is to be evaluated. Requirements analysis methods. Provide a basis for understanding the content to be delivered by a WebApp, the functions to be provided for the end user, and the modes of interaction that each class of user will require as navigation through the WebApp occurs. Design methods. Encompass a series of design techniques that address WebApp content, application and information architecture, interface design, and navigation structure. Construction methods. Apply a broad set of languages, tools, and related technology to the creation of WebApp content and functionality. Testing methods. Incorporate technical reviews of both the content and design model and a wide array of testing techniques that address component-level and architectural issues, navigation testing, usability test- ing, security testing, and configuration testing. In addition to the technical methods that have just been outlined, a series of um- brella activities (with associated methods) are essential for successful Web engi- neering. These include project management techniques (e.g., estimation, sched- uling, risk analysis), software configuration management techniques, and review techniques.7 Isn’t Web Engineering All about Tools and Technology? Tools and technology amplify a technologist’s ability to build computer-based systems. When used properly, good tools allow us to work faster and to create a higher-quality end product. And that’s why every generation of technologists falls in love with tools and technology. The developers of WebApps have been no exception. 7 These techniques, referred to as umbrella activities, are discussed in Chapters 4 and 16. pre23291_ch02.indd 19 pre23291_ch02.indd 19 1/2/08 3:43:48 PM 1/2/08 3:43:48 PM
- 39. CHAPTER 2 WEB ENGINEERING 20 But tools and technology cannot be used in a vacuum. If you don’t really un- derstand the problem, if you have no way of accommodating changes that will in- variably occur, if you haven’t spent some time laying out a viable solution, if you have no intention of ensuring the “solution” that you’ve generated (using powerful tools) meets the needs of your stakeholders, then you’re working in a vacuum. And that’s a recipe for disaster! What we’re trying to say is this: Tools and technology are very important, but they’ll work well only if they’re used within the context of an agile framework for Web engineering and in conjunction with proven methods for understanding the problem, designing a solution, and testing it thoroughly. A vast array of tools and technology has evolved over the past decade as WebApps have become more sophisticated and pervasive. These technologies en- compass a wide range of content description and modeling languages [e.g., HTML, virtual reality modeling language (VRML), XML], programming languages (e.g., Java), component-based development resources [e.g., Common Object Request Bro- ker Architecture (CORBA), Component Object Model (COM) architecture, ActiveX, .NET], browsers, multimedia tools, site authoring tools, database connectivity tools, security tools, servers and server utilities, and site management and analysis tools. An overview of some of the more important tools and technology for Web engineering is presented in Chapter 14. For a more comprehensive discussion, you should visit one or more of the following websites: Web Developer’s Virtual Li- brary (www.wdvl.com), WebDeveloper (www.webdeveloper.com), Developer Shed (www. devshed.com), Webknowhow.net (www.webknowhow.net), or WebReference (www. webreference.com). Agreeing on a Process SAFEHOME The scene: Meeting room for the Web engineering group at CPI Cor- poration prior to the initiation of the project The players: Technical manager, WebE team members The conversation: Technical manager (to the team): So, let’s reca- pitulate. We’ve been tapped to build SafeHome Assured.com. It’s the biggest and certainly the most visible WebApp we’ve ever tried to construct. No doubt, we’ve got a lot of work to do to simply define the thing, but I’d like you guys to begin thinking about how you’re going to approach the engineering part of this project. Team member 1: Seems like we’ve been pretty disorganized in our approach to Web projects in the past. Team member 2: I don’t agree; we always got product out the door. Technical manager: True, but not without a lot of grief, and this project looks like it’s bigger and more complex than anything we’ve done in the past. pre23291_ch02.indd 20 pre23291_ch02.indd 20 1/2/08 3:43:49 PM 1/2/08 3:43:49 PM
- 40. CHAPTER 2 WEB ENGINEERING 21 Web Engineering Best Practices Before we proceed into the core chapters of this book, some plain talk is in order. We recognize that you may choose not to use the WebE process framework and methods that we’ll discuss in detail throughout the remainder of this book. We know that Web engineering teams are sometimes under enormous time pressure and will try to take shortcuts (even if these are ill advised and result in more de- velopment effort, not less). We also accept the fact that some WebE teams want to keep things very informal and reject the notion of a process framework and defined methods as a matter of philosophy. We think that kind of reasoning is erroneous, but it’s your call. What we do hope is that you spend enough time in the remaining chapters to assess each of the practices that we describe, accepting those that seem ap- plicable and rejecting those that don’t. As an absolute minimum, we hope that you and your colleagues will adopt the following best practices whenever you build industry-quality WebApps: 1. Take the time to understand business needs and product objec- tives, even if the details of the WebApp are vague. Many WebApp developers erroneously believe that vague requirements (which are quite common) relieve them from the need to be sure that the system they are about to engineer has a legitimate business purpose. The end result is (too often) good technical work that results in the wrong system being built for the wrong reasons and for the wrong audience. If stakeholders cannot enunciate a business need for the WebApp, proceed with extreme caution. SAFEHOME (CONTINUED) Team member 3: Doesn’t look that hard, but I agree . . . our ad hoc approach to past projects might not work here, particularly if we have a very tight time line. Technical manager (smiling): I want to be a bit more professional in our approach. I went to a short course last week and learned a lot about Web engi- neering . . . good stuff. We need a process here. Team member 2 (with a frown): Process? My job is to build WebApps, not push paper around. Technical manager: Give it a chance before you go negative on me. Here’s what I mean. [He proceeds to describe the process framework described in this chapter and the agile Web engineering philosophy presented to this point.] So anyway, it seems to me that it’s possible to implement an agile process with straightforward activities that won’t result in “pushing a lot of paper around.” Team member 1: Yeah, agility sounds good, and the five steps, er, activities, you mentioned are just common sense. Team member 2: I agree, they’re common sense. That’s why I don’t think we need to implement a process. Team member 3 (laughing): Yeah, but common sense isn’t always so common. Why don’t we give this a chance? pre23291_ch02.indd 21 pre23291_ch02.indd 21 1/2/08 3:43:51 PM 1/2/08 3:43:51 PM
- 41. CHAPTER 2 WEB ENGINEERING 22 If stakeholders struggle to identify a set of clear objectives for the product (WebApp), do not proceed until they can. See Chapters 4 and 5 for details. 2. Describe how users will interact with the WebApp using a scenario- based approach. Stakeholders should be convinced to develop scenarios (Chapters 4, 5, and 7) that reflect how various users will interact with the WebApp. These scenarios can then be used: (1) for project planning and tracking, (2) to guide analysis and design modeling, and (3) as important input for the design of tests. 3. Develop a project plan, even if it’s very brief. Base the plan (Chapter 5) on a process framework (Chapter 3) that is acceptable to all stakeholders. Because project time lines are very short, use a “fine” granularity for your schedule; i.e., in many instances, the project should be scheduled and tracked on a daily basis. 4. Spend some time modeling what it is that you’re going to build. Generally, comprehensive analysis and design documentation is not devel- oped as a part of Web engineering work. However, well-targeted graphical models (Chapters 6 through 12) can and do illuminate important engineering issues. 5. Review the models for consistency and quality. Pair walkthroughs and other types of reviews (Chapter 5) should be conducted throughout a WebE project. The time spent on reviews pays important dividends because it often eliminates rework and results in a high-quality WebApp—thereby increasing customer satisfaction. 6. Use tools and technology that enable you to construct the system with as many reusable components as possible. A wide array of WebApp tools is available for virtually every aspect of the WebApp construc- tion (Chapter 14). Many of these tools enable a Web engineer to build signifi- cant portions of the application using reusable components. 7. Don’t reinvent when you can reuse. A wide range of design patterns have been developed for WebApps. These patterns allow a WebE team to develop architectural, navigation, and component-level details quickly using proven templates. See Chapter 13 for a detailed discussion. 8. Don’t rely on early users to debug the WebApp—design compre- hensive tests and execute them before releasing the system. Users of a WebApp will often give it one chance. If it fails to perform, they move elsewhere—never to return. It is for this reason that “test first, then deploy” should be an overriding philosophy, even if deadlines must be stretched. See Chapter 15 for details. pre23291_ch02.indd 22 pre23291_ch02.indd 22 1/2/08 3:43:52 PM 1/2/08 3:43:52 PM
- 42. CHAPTER 2 WEB ENGINEERING 23 Where We’ve Been . . . Where We’re Going As we begin our consideration of Web engineering and the process framework that acts as its foundation, agility becomes a very important concept. As a Web engineer, you have to be quick on your feet. Your job is to build high-quality WebApps—quickly. But as you do this, you have to accommodate a system that continues to evolve as work is conducted. You have to adapt a generic framework for each WebApp increment and integrate a collection of WebE methods and tools into the framework. You have to follow a set of agility principles and a collection of best practices that guide the team toward success. As we move into Chapter 3, you’ll learn more about the WebE process frame- work. More importantly, we suggest a set of WebE actions and tasks that can serve as a basis for adapting the framework to the very specific needs of the problem, the people, and the project. References [Agi03] The Agile Alliance Home Page, www.agilealliance.org/home (accessed July 24, 2007). [Aoy98] Aoyama, M., “Web-based Agile Software Development,” IEEE Computer, November/December 1998, pp. 56–65. [Fow01] Fowler, M., and J. Highsmith, “The Agile Manifesto,” Software Develop- ment Magazine, August 2001, www.sdmagazine.com/documents/s=844/sdm0108a/ 0108a.htm (accessed July 24, 2007). [Jac02] Jacobson, I., “A Resounding ‘Yes’ to Agile Processes—But Also More,” Cutter IT Journal, vol. 15, no. 1, January 2002, pp. 18–24. [Pre98] Pressman, R. S. (moderator), “Can Internet-Based Applications Be Engi- neered?” IEEE Software, September 1998, pp. 104–110. [Pre09] Pressman, R. S., Software Engineering: A Practitioner’s Approach, 7th ed., McGraw-Hill, 2009. pre23291_ch02.indd 23 pre23291_ch02.indd 23 1/2/08 3:43:52 PM 1/2/08 3:43:52 PM
- 43. 24 24 24 A WEB ENGINEERING PROCESS Some people believe that an organization can fully define a process for WebApp development before the fact; put it on the shelf (metaphori- cally); and then take it down, dust it off, and apply it as is when a new Web engineering project appears. Sadly, that’s not how things work. It is true that you and your colleagues can develop an effective WebE process framework and apply it to each WebApp project that comes along. But as we noted in Chapter 2, the framework must be adapted to the specific characteristics of the problem, the project, and the people who will specify the need and do the work. A generic WebE process framework provides you with the ability to gain an understanding of what the problem is (both in terms of business context and technology). Armed with this fundamental understanding, you work to refine or adapt the basic process to meet the specific needs of the problem at hand. You consider the culture of the team that will do the work, the desires of your customers, the degree of stability in the problem requirements, and the demands of your managers (for oversight, time-to-market, quality). As work begins, you continuously adapt the process to be sure that: (1) it does not get in the way of agility, (2) that it truly does accommodate the needs of WebE team members, (3) that it produces only those inter- mediate work products that enable you to move rapidly toward the deliv- ery of a planned WebApp increment, (4) that it allows you to continually assess the quality of your work, and (5) that it enables you to accommo- date the changes that have already begun to impact your work schedule and approach. In essence, the framework remains the same, but the way you apply it will change with every project and every project team. The framework is applied iteratively as each WebApp increment is created. Defining the Framework Before we define a process framework for WebE, we must reiterate a few realities that are encountered in most WebApp projects: 1. Requirements evolve over time. When you begin a WebApp project, there may be uncertainty about some elements of the business strategy, the content and functionality to be delivered, interoperability issues, and many other facets of the problem. 3 C H A P T E R pre23291_ch03.indd 24 pre23291_ch03.indd 24 1/2/08 3:44:09 PM 1/2/08 3:44:09 PM
- 44. 25 2. Changes will occur frequently. Because uncertainty is an inherent part of most WebApp projects, changes to requirements are common. In addition, user feedback (based on an assessment of delivered increments) and chang- ing business conditions may drive change. 3. Time lines are short. This mitigates against the creation of voluminous engineering documentation, but it does not preclude the simple reality that problem analysis, design, and testing must be documented in some manner. Because of these realities, WebApps are often delivered incrementally. That is, frame- work activities will occur repeatedly as each WebApp increment is engineered and delivered (Figure 3.1). In addition, the agility principles described in Chapter 2 should be applied. However, these principles should not be applied dogmatically, and it is sometimes reasonable to adopt them in spirit without necessarily building each into the process framework that you’ve chosen. FIGURE 3.1 A WebApp delivered in four increments. Complete WebApp Increment 1 Planning Modeling Construction Deployment Communication WebE process framework Increment 2 Planning Modeling Construction Deployment Communication WebE process framework Increment 4 Planning Modeling Construction Deployment Communication WebE process framework Increment 3 Planning Modeling Construction Deployment Communication WebE process framework CHAPTER 3 A WEB ENGINEERING PROCESS pre23291_ch03.indd 25 pre23291_ch03.indd 25 1/2/08 3:44:10 PM 1/2/08 3:44:10 PM
- 45. CHAPTER 3 A WEB ENGINEERING PROCESS 26 With these issues in mind and referring to Figure 3.2, we expand our discus- sion of the WebE process framework presented in Chapter 2. Communication. Within the WebE process, communication is character- ized by three WebE actions: formulation, elicitation, and negotiation. Formu- lation defines the business and organizational context for the WebApp. In addition, stakeholders are identified; potential changes in the business environment or requirements are predicted; and integration between the WebApp and other business applications, databases, and functions are defined. Elicitation is a requirements-gathering activity involving all stake- holders.1 The intent is to describe the problem that the WebApp is to solve (along with basic requirements for the WebApp) using the best information available. In addition, an attempt is made to identify areas of uncertainty and where potential changes will occur. Finally, negotiation is often required to reconcile differences between various stakeholders for the project. 1 As we’ve noted in Chapter 2, a stakeholder is any person who has a vested interest in the WebApp. A stakeholder may be actively involved in defining requirements (e.g., marketing peo- ple), managing the business aspects of a project (e.g., business managers), using the WebApp (e.g., end users), or developing the WebApp itself (e.g., the WebE team). FIGURE 3.2 Process flow with WebE actions. Planning Scheduling Modeling Construction Deployment Communication WebE process framework Estimation Risk analysis Monitoring Formulation Negotiation Elicitation Analysis Design Coding Testing Delivery Evaluation Each increment starts here Each increment delivered here pre23291_ch03.indd 26 pre23291_ch03.indd 26 1/2/08 3:44:10 PM 1/2/08 3:44:10 PM
- 46. CHAPTER 3 A WEB ENGINEERING PROCESS 27 Planning. The overall number of WebApp increments is identified2 and a brief project plan (Chapter 5) for the next WebApp increment to be deployed is created. Resources are estimated for the increment, risks are considered, tasks are selected and scheduled, and project tracking and monitoring commence. In most cases, the planning work product consists of a task definition and a time line schedule for the time period (usually measured in weeks) projected for the development of the WebApp increment. Modeling. Conventional software engineering analysis and design tasks are adapted to WebApp development, merged, and then melded into the WebE modeling activity (Chapters 6 through 13). The intent is to develop agile analysis and design models that define requirements and at the same time represent a WebApp that will satisfy them. Construction. WebE tools and technology (Chapter 14) are applied to con- struct the WebApp that has been modeled. Once the WebApp increment has been constructed, a series of rapid tests are conducted to ensure that errors in design (e.g., errors in content, architecture, interface, and navigation) are uncovered. Additional testing addresses other WebApp characteristics. Deployment. The WebApp is configured for its operational environment. It is then delivered to end users, and an evaluation period commences. Evaluation feedback is presented to the WebE team, and the increment is modified as required. These five WebE framework activities (with actions superimposed) are applied us- ing the incremental process flow illustrated in Figure 3.2. Incremental Process Flow In Chapter 1, we introduced you to the CPI Corporation and its SafeHome security products and SafeHomeAssured.com—a comprehensive WebApp that will serve as the hub for product marketing and sales, as well as the focus for a new generation of security monitoring services. At the moment, nothing exists but a broad strategy and a few good ideas. You’ve been chartered with the job of building a WebE team that will create the WebApp. The need is immediate, and a Web presence must be up and running as soon as possible. It’s obvious that you have to be agile. It’s also obvious that things will change (probably drastically) as you begin to engineer the WebApp. You decide to use the activities defined for the generic process framework— communication, planning, modeling, construction, and deployment—and that the 2 The number of increments to be delivered may change as feedback from the deployment of early increments is received. pre23291_ch03.indd 27 pre23291_ch03.indd 27 1/2/08 3:44:11 PM 1/2/08 3:44:11 PM
- 47. CHAPTER 3 A WEB ENGINEERING PROCESS 28 only reasonable way to deliver the WebApp is in increments. What might those increments be? In Chapter 4, we’ll discuss a specific technique for defining deliverable WebApp increments. For now, we’ll only note that these increments are identified as part of the first iteration through the communication activity. The list of increments may be further refined with every subsequent iteration. How Are Framework Activities Conducted? Referring once again to Figures 3.1 and 3.2, the iterative process flow will be applied to each increment. The very first iteration focuses primarily on defining overall WebApp requirements and identifying the increments to be deployed in subsequent iterations. The first iteration. The first communication activity is initiated. The intent is to define business context, establish overall requirements, create a set of usage scenarios, negotiate conflicting needs among stakeholders, and then from this in- formation derive the set of WebApp increments that is to be delivered. Detailed guidelines for conducting these tasks are presented in Chapters 4 and 5. For now, we’ll assume that the first increment to be deployed is an informational WebApp that introduces the CPI Corporation and its products. Stakeholders indicate that this informational WebApp must be deployed in one week! The second iteration. Even though time is very short, you commit yourself to the WebE process framework. The next morning you initiate the communication activity for the first increment by conducting a 1-hour meeting with stakeholders. You get a reasonably good picture of what is required for the increment. You learn (much to your relief) that all content necessary for the increment is available in preexisting files and an in-house graphic artist is already at work designing the aesthetic look that CPI wants. After the meeting, you review your notes: Logo and graphics—need aesthetic design. One- or two-paragraph introduction. CPI mission statement (file exists) A word to visitors (someone will write this tomorrow) Basic navigation bar will look like . . . About the company Our offerings Home security products (hierarchical at next level) Monitoring services (a list) Our Technology (the new sensor) Contact us Other issues: Informational content will change over time. pre23291_ch03.indd 28 pre23291_ch03.indd 28 1/2/08 3:44:11 PM 1/2/08 3:44:11 PM
- 48. CHAPTER 3 A WEB ENGINEERING PROCESS 29 This “home page” will be the navigation starting point for content and functions required for subsequent increments. The requirements for the first SafeHomeAssured.com increment are straightforward. Because you’ve decided to follow the WebE process framework, your next ac- tivity is planning. Since all content exists and no functionality is to be implemented at this stage, you decide to do the work yourself (while thinking about assembling a small WebE team for subsequent increments). Over the next half-hour, you create a simple time line: Day 1: Create a prototype layout (a model) of the WebApp. Collect and review all existing CPI content and graphics. Get stakeholder feedback on prototype, if possible. Day 2: Using the prototype as a guide, begin construction of the increment. Build navigation bar. Lay out content areas. Integrate graphics, links, etc. Test all links for validity. Review all content for completeness and correctness. Day 3: FTP all files to (an existing) domain. Perform navigation tests. Deployment: Inform selected stakeholders that the increment is available. Day 4: Poll stakeholders for feedback. Make modifications based on stakeholder feedback. The plan for the first SafeHomeAssured.com WebApp increment is complete. Model- ing, construction, and deployment follow over the next 3 to 4 days. The next iteration. As soon as deployment (for the first increment) is com- plete, you’re ready to initiate the next iteration of the WebE process. For SafeHome Assured.com, the communication activity during this second iteration will identify the requirements (including content and functionality) for the second increment.3 So you restart the process flow at the beginning, performing the communication activity for this increment. The tasks you select to populate each framework activ- ity for the increment may differ from the tasks performed for the preceding incre- ment, but the overall process flow remains the same. As increments become more complex, the number of work tasks required for each framework activity, and often the complexity of those tasks, is likely to grow. The implication is clear: your approach to a given framework activity for a particular increment may not be the same as your approach for the same activity 3 For the purposes of this discussion, we’ll assume that the second increment delivers the capa- bility to select and download product specifications and related information. pre23291_ch03.indd 29 pre23291_ch03.indd 29 1/2/08 3:44:12 PM 1/2/08 3:44:12 PM
- 49. CHAPTER 3 A WEB ENGINEERING PROCESS 30 in the next increment. With each iteration, framework activities must be adapted and refined. As you move through each iteration, agility should be your watchword. You and your stakeholders are a team, and teammates talk to one another— communicate as part of each increment flow. You and your colleagues should plan, but only to the extent that it provides a route to the end result and a way to track progress. You should model, but only when the increment to be built is complex or the requirements or design approach are not as clear as you’d like. You’ll construct the increment with an eye toward testing and perform tests before you deploy the increment. You’ll listen to end-user feedback, using it to correct problems with the deployed increment, but also to guide your work as you move forward to other increments. You’ll also conduct umbrella activities4 so that quality is ensured, change is controlled, risk is managed, and the project is supervised. How Is the Framework Refined? The Web engineering actions and tasks required to refine each framework activity are left to the discretion of the Web engineering team. In some cases, a framework activity is conducted informally. In others, a distinct set of actions will be defined and conducted by team members. When an action is complex (e.g., design), it may be further refined into a set of Web engineering tasks (e.g., aesthetic design, con- tent design, architecture design, navigation design, and component design). But how do you decide which WebE tasks should be applied? To answer this question, the scope of the framework activity for a specific increment must be un- derstood. For example, communication is a framework activity that is applied in all Web engineering projects. Consider the refinement of communication for two dif- ferent increments to be delivered as part of the SafeHomeAssured.com WebApp. For the first deliverable increment—an informational WebApp—you must understand the content that is to be presented, the overall aesthetic (e.g., color scheme, layout, menu format, typefaces, and styles) that is desired for the website, the number of distinct categories of information to be presented, and related infor- mation. Because your overriding philosophy stresses agility, you want to determine this information as quickly as possible (after all, you have only 5 days to deploy the WebApp increment). Hence, communication involves only a single action: meet with the customer. Recalling our discussion earlier in the chapter, no formal work product is pro- duced, and the time required to ask and answer the questions implied by these tasks is relatively short. 4 Umbrella activities are discussed later in this chapter. pre23291_ch03.indd 30 pre23291_ch03.indd 30 1/2/08 3:44:12 PM 1/2/08 3:44:12 PM
- 50. CHAPTER 3 A WEB ENGINEERING PROCESS 31 Now consider the communication activity for the third deliverable SafeHome- Assured.com increment. For the purposes of this discussion, let’s assume the third increment enables e-commerce functionality. For this increment, the communica- tion activity is more complex. Three actions, formulation, elicitation, and negotia- tion, will be conducted. Work tasks will be defined for each action. You must understand the business context (formulation), identify a specific set of content and functional requirements (elicitation) for e-commerce (e.g., forms- based processing requirements, product pricing requirements, shipping costs, taxes, special orders), and reconcile differences among stakeholders (negotiation). You’ll also have to identify constraints and performance requirements. You still have to meet with the stakeholders, but the duration of the meeting(s) and the number of WebE tasks that must be performed will both grow. It’s likely that you’ll produce a few formal work products (e.g., usage scenarios for various user categories, a sketch of the order entry form) and spend more time reviewing them with your stakeholders. Alternatively, it may be possible to use a preexisting e-commerce template (we would recommend this approach, see Chapter 13) that will enable you to present a prototype to your stakeholders, thereby expediting the communication task. Refining the WebE Process for Each WebApp Increment SAFEHOME The scene: Meeting room for the Web engineering group as work on the first increment—an informational WebApp for SafeHome—ends The players: Technical manager, WebE team members The conversation: Technical manager (to the team): Looks like we’ll get the first increment online on Wednesday. Team member 2: It was a piece of cake. But the next increment looks a bit more complex and the ones after that . . . Team member 1: There’s something I don’t under- stand. Getting the requirements for the first increment was easy—simple conversation and then accessing ex- isting content. But the other stuff is more complicated, and we don’t have the requirements yet. Team member 3: True. We have to begin work on Thursday, and there’s a lot that’s unclear. Technical manager: That’s why we begin the next increment with communication, again. Team member 1: But what’s the process for the communication activity? For the first increment it was nothing but a quick conversation. Technical manager: Like we decided. We tune the process—and that means the communication activity as well as others—to the increment at hand. This time we’ll have to be a bit more formal and define specific communication tasks. Team member 2: And we’ll use those for every remaining increment? Technical manager: Nope, every time we begin a new increment, we’ll look at its complexity and decide on the “task set” that seems appropriate. Team member 3 (smiling): Agile and adaptable. Technical manager: That’s us! pre23291_ch03.indd 31 pre23291_ch03.indd 31 1/2/08 3:44:12 PM 1/2/08 3:44:12 PM
- 51. CHAPTER 3 A WEB ENGINEERING PROCESS 32 Generic Actions and Tasks for the WebE Framework Although it’s necessary to adapt your own set of Web engineering actions and tasks, you have to start somewhere. For this reason we’ve provided an overview of the generic actions and tasks that can serve as a starting point as you and your team refine each framework activity for the WebApp increment that is to be deliv- ered. It is important to note that each of the activities presented here is considered in much greater detail in later chapters. How Should the Communication Activity Be Refined? If you don’t know your destination, then it is extremely difficult to get where you need to go and to know when you might have gotten there. That’s common sense, and yet many Web developers start their journey toward the development of a WebApp with little or no idea where they’re going. They may ultimately reach an acceptable destination, but they’ll take many wrong turns and arrive at numerous dead ends as they travel. As a result, they’ll be late. Sometimes, they never arrive. At other times they get there, but don’t know when to stop, and so keep going unnecessarily. Communication is the activity that establishes the “destination” for a WebApp project. For a simple destination, there are a relatively small number of informal actions and tasks required to be sure you know where you’re going. If the destina- tion is more difficult to describe, you’ll need to refine the communication activity with more care. The following tasks and related questions should get you started: • Identify business stakeholders. Exactly who is the “customer” for the WebApp? What businesspeople can serve as experts and representative end users? Who will serve as an active member of the team? What is the degree of consensus among stakeholders? Who is the final arbiter when disputes between stakeholders arise? • Identify user categories. How many different types of users will interact with the WebApp? What is the background and sophistication of each user category? Who will identify special needs for each user category, and what are those needs? What special content and functionality are required by each user category? • Formulate the business context. How does the WebApp fit into a broader business strategy? Is the strategy well established, and are existing business rules well understood? • Define key business goals and objectives for the WebApp. How is the success of the WebApp to be measured in both qualitative and quantitative terms? If there are multiple objectives, what are their priorities? Do different pre23291_ch03.indd 32 pre23291_ch03.indd 32 1/2/08 3:44:14 PM 1/2/08 3:44:14 PM
- 52. CHAPTER 3 A WEB ENGINEERING PROCESS 33 stakeholders have different goals and objectives? Are all goals and objec- tives consistent with one another? • Identify the problem. What specific problem does the WebApp solve? What information is produced for the end user? What information is input by the end user? What functionality is required to manipulate data? What stored information does the WebApp use? Which existing systems will interoperate with the WebApp? • Define informational and applicative goals. What classes of content are to be provided to end users? What is the status of this content? How dynamic is the content; that is, how often does it change? What functions and user tasks are to be accomplished when using the WebApp? How stable are the required functions? • Gather requirements. What user tasks will be supported by the WebApp increment? What content is to be developed? What interaction metaphor will be used? What computational functions will be provided by the WebApp? How will the WebApp be configured for network utilization? What navigation schema is desired? What constraints exist for the increment? What special performance requirements must be considered? • Develop usage scenarios. Have all categories of users who will interact with the increment been considered? Are usage scenarios complete and consistent with increment requirements? Do usage scenarios require further refinement? As we noted earlier, if the destination is relatively simple, each of the communi- cation tasks (and the questions noted) can be accomplished informally by meet- ing with appropriate stakeholders and taking notes. However, if the destination is more complex, a more structured approach to each of the tasks may have to be implemented. We’ll discuss this approach in more detail in Chapter 4. What Tasks Are Required to Develop an Increment Plan? The communication activity has provided you with a destination, and now you’re ready to plan the journey. Your route may be reasonably complex. Therefore, you decide to plan the route in stages by defining way points that will ensure that you’re heading in the right direction and making step-by-step progress toward your ultimate goal. In actuality, the first iteration of the communication activity establishes the way points (WebApp increments), but it is the planning activity that defines the re- sources that will be required to achieve each way point and estimates the time that will be required to get there. The following tasks and related questions should help you as you develop an incremental plan: pre23291_ch03.indd 33 pre23291_ch03.indd 33 1/2/08 3:44:15 PM 1/2/08 3:44:15 PM
- 53. CHAPTER 3 A WEB ENGINEERING PROCESS 34 • Refine your description of the WebApp increment to be delivered. Do requested changes (by any stakeholder) require a modification in the number or definition of increments that remain to be delivered? If modifica- tions are required, what changes in content and functionality are necessary? How much effort is likely to be expended on each increment that remains to be delivered? How much calendar time will be expended on each increment? What is the estimated deployment date for each increment? • Select the WebApp increment to be delivered now. Is there enough in- formation about the increment to begin other framework activities? Do you have a clear understanding of the content and functionality to be delivered by the increment? Are constraints and performance issues clearly under- stood? Are all necessary usage scenarios available and complete? • Estimate the effort and time required to deploy the increment. How much effort (person-days) and time (calendar days) will be required to model, construct, and deploy the increment? What resources (people, hard- ware, software) will be required to do the work? • Assess risks associated with the delivery of the increment. What risks should be addressed during the development of this increment? How will high-probability, high-impact risks be mitigated? What long-range risks should be considered? • Define the development schedule for the increment. How will tasks be allocated along the time line for the increment? What intermediate mile- stones will be established? • Establish work products to be produced as a consequence of each framework activity. What work products (e.g., written scenarios, sketches, models, documents) will be developed as work on the increment proceeds? • Define your approach to change control. How will changes to content and functionality be requested, evaluated, and executed within the context of other development activities? • Establish your quality assurance approach. How will the team assess quality as the increment is modeled, constructed, and deployed? What, if any, reviews will be conducted? What, if any, metrics will be used? Since increments are often developed in weeks, not months, it’s reasonable to ask whether planning is justified for Web engineering. It’s always a good idea to estab- lish the route to your destination, but it’s foolhardy to spend so much time planning the route that you have little time left to get there. We advocate agile planning for each increment—a single, team-oriented meeting in which all WebE team mem- pre23291_ch03.indd 34 pre23291_ch03.indd 34 1/2/08 3:44:15 PM 1/2/08 3:44:15 PM
- 54. CHAPTER 3 A WEB ENGINEERING PROCESS 35 bers assist in planning. We also advocate adaptive planning. Things happen, and as a consequence, the plan may have to be modified as the WebApp increment is engineered. What Is Modeling? In the context of this Web engineering process framework, modeling is an activity that creates one or more conceptual representations of some aspect of the WebApp to be built. A conceptual representation encompasses one or more of the follow- ing forms: written documents, sketches, schematic diagrams, graphical models, written scenarios, paper or executable prototypes, and executable code.5 Two Web engineering actions occur during modeling: analysis and design. What Analysis Modeling Tasks Can Be Applied? Analysis examines stakeholder requirements using information gathered during the communication activity as a starting point. In many instances, the information gathered during communication is sufficient as a basis for building an increment, and there is no need for analysis modeling. However, when the requirements for an increment are complex, it is sometimes a good idea to create a model that re- fines your understanding of the WebApp. In general the analysis model focuses on WebApp content, modes of interaction (including navigation), functionality, and the technical configuration6 of the WebApp. The following tasks and related questions should help determine whether to develop an analysis model: • Decide whether a requirements model is needed. Does existing infor- mation (gathered during the communication activity) provide sufficient de- tail about: (1) WebApp content, (2) required modes of interaction, (3) required functionality, and (4) technical configuration issues? Have usage scenarios been developed in sufficient detail to guide the design and construction activities? If this information exists and is complete, there is no need for analysis modeling for the increment. If the information is incomplete or im- plies a degree of complexity that demands further examination, proceed to the analysis modeling tasks that follow. • Represent WebApp content. What content is to be presented? What is its origin? Who is responsible for acquiring and developing it? Is it advisable to organize content into a collection of classes? Are the relationships between content classes complex? Which content classes are static (do not change 5 These conceptual representations are discussed in more detail in Chapters 6 through 13. 6 In this context, the technical configuration refers to the hardware and software environment in which the WebApp will reside. pre23291_ch03.indd 35 pre23291_ch03.indd 35 1/2/08 3:44:15 PM 1/2/08 3:44:15 PM
- 55. Other documents randomly have different content
- 56. afternoon; for he looked a gentleman to the backbone, and as such, his hostess—who was very short of men—smiled upon him graciously. "So glad you were able to come," she cooed. "Miss Waller," to the spinster, who had just arrived, "may I introduce my friend, Dr. Inglis?" "I have already made his acquaintance," was the suave answer; and then Harold, to his surprise, was greeted by Mrs. Burnside, looking very fair and sweet in a cool white linen gown. He had not expected to meet her; he naturally supposed her place to be by the bedside of her sick child. In truth, she was only present at her aunt's urgent entreaty. "I'm afraid she must be rather heartless," thought the young doctor, feeling oddly disappointed. He had not hitherto attributed want of feeling to the owner of those pathetic blue eyes. Nevertheless, as sets were being made up, he asked her to be his partner, she being famed in Beachbourne as a tennis-player. She complied; but the set was not a success. He could not have believed that Mrs. Burnside could play so badly; they were beaten by six games to two. "I am so sorry," she said humbly, as they quitted the court. "I know it was all my fault; but I really couldn't play—I was thinking of Doris all the time." Her lips quivered, so that he could no longer imagine her heartless. "Your little girl will be well in a few days—there is really no cause for anxiety," he answered gently, angry with himself for having misjudged her. "That is what Aunt Caroline says, and she insisted on my coming," plaintively returned May; but just then Miss Waller appeared, resplendent in mauve satin, with a stout, black-haired, middle-aged, and shrewd-looking man, very carefully dressed, in tow.
- 57. "I came to look for you, dear," she began very sweetly to her niece, merely giving a cold bow to Harold. "I want to introduce Mr. Lang to you. He knows our friends the Wingates in town." With that, the excellent spinster turned away; and May, finding no resource save to accept the basket-chair in the shade proffered by the stranger—as Harold had prudently effaced himself—prepared for a tête-à-tête with a man she had never seen before in her life. "It was very kind of you to come so promptly, Dr. Inglis."
- 58. CHAPTER III. "Manners Maketh Man." "Do you mind my smoking?" began Mr. Lang, after a moment's keen scrutiny of the graceful figure beside him. Hardly waiting for permission, he produced a gold case and lighted a cigarette. "Been playing tennis, haven't you?" he continued in an off-hand way. "Stupid game, not half so good as golf—you should try golf." "I have tried it, and I don't like it." "Beginners seldom do. It's a fine game, for all that. You live with your aunt, don't you?" "Yes, in Victoria Square." "Do you like Beachbourne?" She hesitated a moment before replying, "Yes." "I suppose it's like all these provincial towns—heaps of gossip and scandal, eh? But you should be in London now, Mrs. Burnside. There hasn't been as gay a season for years. I shouldn't be here now, I can tell you, but I got a touch of fever last time I was at Johannesburg, and, as I can't quite shake it off, my doctor ordered me complete rest for a fortnight. So I came down here to stay with the Stevensons. I met them last year at Homburg, and ever since they've been pestering me with invitations to Beachbourne."
- 59. The set was not a success.—p. 399. "Oh, have you been out in Africa?" returned May, thinking it best to ignore his flattering reference to his entertainers. "Spent nearly twenty years there. I can remember when there wasn't a gold mine on the Randt. And, though I've come back to England for good now, I generally run over about twice a year. It's just a nice little trip to the Cape, and they really do you very well on the mail steamers," he condescendingly added, as he lighted another cigarette. "By-the-bye, this case is made of African gold—a nugget I found myself in the claim which was the beginning of the Springkloof Mine. You've heard of the Springkloof, of course?" She shook her head, and he looked at her with evident pity for her ignorance. "I didn't think there was anybody nowadays who hadn't heard of the Springkloof!" "I'm afraid you'll think us rather behind the times at Beachbourne," she said, as she rose, hoping to shake off her new acquaintance; but
- 60. he rose, too, and kept by her side as she strolled through the beautiful grounds, speaking first to one friend and then to another. "Not many pretty girls here, I must say," he observed disparagingly, as they approached the house, in quest of the tea-room. "Are you an admirer of beauty?" asked May, with a rather sarcastic glance at his tubby figure. "Quite so. I love the best of everything there is. As soon as I can find a girl pretty enough, I intend to marry," he replied with perfect gravity. "It's rather lonely all by myself in Palace Gardens. Do you like the Palace Gardens houses, Mrs. Burnside?" "I've never been in one, and I don't even know where they are. I know very little about London, and very few people there—just the Wingates, and one or two others." "Are the Wingates any relation?" "Oh, no, only old friends of my aunt's. I hardly know them." "Well, it's not much loss. I don't mean any disrespect to your aunt, but old Mother Wingate isn't a woman I should ever wish to confide in, myself. She's always trying to catch me for one of her plain daughters—dear Maggie or dear Amy! By the way, what's your Christian name, Mrs. Burnside?" "May." "And, by Jove, it suits you! So often girls' names don't. You find Lily as black as a crow, and Rose as sallow as she can be, and Queenie a little, insignificant dowdy with a turned-up nose!" He talked in this carping strain while he consumed a fair amount of refreshments, none of which, however, were good enough for his critical taste. He evidently thought a great deal about eating and drinking, for he incidentally mentioned that he gave his chef two hundred a year. "What a waste!" was on the tip of May's tongue, as she thought how useful even a tenth of that sum would be to herself. The tea was
- 61. cosily set out on a number of little tables in the spacious, old- fashioned dining-room. Gay groups were seated at each, and not far off was Harold Inglis, talking cheerfully with two of his host's daughters. May glanced from him to her companion, noticing how common and plebeian Mr. Lang looked when contrasted with him. As she quitted the table Harold, who had apparently been lying in wait, crossed over to speak to her. "Would you like to play again, Mrs. Burnside? I can easily make up a set, if you wish." But at this moment appeared Miss Waller, apparently from nowhere, to throw cold water on the proposal. "I think you had better not run about any more this hot afternoon, love. You really must not tempt her, Dr. Inglis." "There's croquet," suggested Harold; "shall we play at that?" And, though in general she detested croquet, May assented quite eagerly, only anxious to shake off Mr. Lang. Miss Waller could not well interfere again, and Mr. Lang did not play croquet, but he and the spinster sat on a garden seat close by till the game was finished, rendering it difficult for Harold to say a word which the watchful pair did not overhear. Divining from her erratic play that May's mind was still running upon her sick child, he seized the opportunity, when they were both searching for a ball which had rolled into the shrubbery, to say kindly: "Don't fret about Doris. I assure you there's no need. The malady must run its course, and she'll be all right afterwards. Only you must be careful she doesn't get a chill." "I wish she could have you to attend her, instead of Dr. Ellis. She detests him because he once deceived her about a powder she had to take. But my aunt likes him——" "I believe he is a very clever man," hurriedly interposed Harold, mindful of professional etiquette. "Doris will be quite safe with him; indeed, she hardly needs a doctor." "My aunt is always at home on Tuesdays—I hope you will come to see us," responded May, grateful for his manifest sympathy. She
- 62. knew he had few friends in Beachbourne, and resolved to do what she could to introduce him. His face lighted up unmistakably. "Thank you so much, Mrs. Burnside! I shall be delighted to come, and I'll not forget Tuesday." Miss Waller was in a most complacent frame of mind as they drove home through the beautiful June evening. "What a fortunate thing I forbade you to be so foolish as to stay at home to nurse Doris!" she began. "Mr. Lang is a man worth knowing; he made an enormous fortune in South Africa—a million at least—and Mrs. Stevenson says his house in Palace Gardens is simply lovely. I'll ask him to dinner, to meet some nice people." May's delicate face flushed. "He's not a gentleman!" she said. "I daresay he was not of much extraction originally, but what does that matter nowadays? Money levels all distinctions; and I can see Mrs. Stevenson would be only too glad to catch him for Edith." "I thought his manner insufferably rude!" "My dear, that's because he's so run after in London; it always spoils a man to have dozens of girls angling for him. But he was undoubtedly struck by you; and I don't think you were very wise to go and play croquet with that Dr. Inglis as you did. He has agreeable manners, but he has not a penny-piece; and I don't believe he'll ever get a practice here." "I'm sorry for him, aunt, and—and I thought it only civil to ask him to call——" Miss Waller's brow contracted. "I think you might have consulted me first. At best he is only a detrimental, and there are far too many here already; but you always were quixotic, May!"
- 63. CHAPTER IV. Lulu. Whit Sunday—which was late that year—was simply glorious, the heat being tempered by a delicious sea breeze. A vivacious, dark- eyed girl, who accompanied Harold Inglis along the parade after morning service, stopped again and again to gloat over the sapphire sea, tumbling in, foam-crested. "How jolly for you, Harold, living in this delicious place!" she exclaimed. "You ought to look better than you do; you are much thinner than you were." He evaded the subject, not wishing to sadden his favourite sister, Lulu, with his shifts and privations. She had come down to Beachbourne to spend Whitsuntide with her brother, glad to escape from the stuffy London office in which she had to work hard for a living. "Oh, Harold! who are these smart people coming along?" They had already passed many well-dressed groups of residents, but none presenting so imposing an appearance collectively as did stately Miss Waller, in heliotrope, May Burnside, in an exquisite costume of pale grey silk and chiffon, Doris, a vision of childish prettiness in white muslin, and two or three equally well-dressed men, conspicuous amongst whom was Mr. Lang. Harold's colour rose as he lifted his hat, whilst Lulu eagerly exclaimed, "Oh! who is that pretty girl in grey? She looks quite fit for the Park!" He explained, secretly glad that his sister should admire his divinity; but it was fortunate he could not hear what Miss Waller was meanwhile saying to her niece: "Who is that common-looking girl with Dr. Inglis? She is most atrociously dressed."
- 64. It must be confessed that poor Lulu, who had little money for dress, fell far below the Victoria Square standard. "Looks like a little dressmaker," sneered one of the men. "A dressmaker would have better clothes," observed Miss Waller. Her eyes dwelt complacently on her niece's graceful figure, as she spoke, and she was pleased to see how close Mr. Lang—who had overtaken them in coming out of church—kept to May's elbow, despite the black looks of Doris, who disliked him. The child was now quite well again, some days having elapsed since the garden party. "What are you going to do this afternoon. Mrs. Burnside? Will you come for a drive?" presently asked Mr Lang. But May did not approve of Sunday driving. "I promised to take Doris to the flower service, thank you." "Why, you've been to church once already, Doris! You'd much better persuade your mother to bring you for a drive with me," cajoled he; but the child burst out, "No, I don't like you, and I don't want to drive with you!" so resolutely that he could not press it. Miss Waller frowned angrily. "Really, May, the way you spoil Doris is beyond all reason. She is the rudest little girl I ever saw!" And, to soothe the plutocrat's wounded feelings, she insisted upon his coming home to luncheon with her. He was now a constant visitor in Victoria Square, for, having terminated his stay with the Stevensons, he had taken rooms at the principal hotel. Whilst May, in her costly gown, sat chafing beneath Mr. Lang's glances of insolent admiration, at her aunt's luxuriously appointed table, Harold and Lulu Inglis were very merry and happy over the plainest fare in his bare sitting-room. They had not met for a long time, and a cheap Whitsuntide excursion was the reason of her presence now. As soon as they had finished, they started for the shore. Sitting on a big stone, beneath the shade of the cliffs, they had a delightful chat, until Lulu suddenly exclaimed: "Oh, Harold! Here's that pretty girl in grey we saw this morning!"
- 65. Doris, who loved the sea, had coaxed her mother to come down on the shore after the service, and, seeing his companion, May bowed to Harold, and would have passed on, but he detained her. "May I introduce my sister, Miss Lucy Inglis, Mrs. Burnside?" There was something so frank and friendly about Lulu that very soon, as Doris announced she was tired and wanted to rest, they were all seated upon the big stone, upon which Miss Inglis insisted on spreading her jacket, to protect May's dainty dress. Whilst his sister expatiated on the delights of Beachbourne, and wondered why her raptures evoked so little response from the young widow, Harold sat pondering whether he dare invite Mrs. Burnside to come to tea in his bare and shabby rooms. To his delight, she instantly accepted the invitation; eager, in truth, to escape from the hated society of Mr. Lang. Harold then turned to Doris, gaily asking whether she would come too. "Yes, I will," she answered with childish bluntness. "I like you, but I don't like Dr. Ellis—nasty man!—and I hate Mr. Lang." "You shouldn't hate anybody, Doris," reproved May. "But Mr. Lang calls me Little Crosspatch, and it's very rude of him to call me names, mummy." "Bravo, Doris!" cried Lulu mischievously, as they turned to go. "Stick up for your rights—you'll be a 'New Woman' when you grow up." "I hope so," said May, in a low voice, to the amazement of Miss Inglis, who exclaimed, with a glance at the costly equipment of the speaker: "I should never have expected you to utter such a wish, Mrs. Burnside!" May smiled with quiet bitterness. "I have no wish to see Doris speak on a platform, or go in for a man's profession; but I do feel, more and more, that it is better for women to be independent, whether they marry or not." "Why, that's just what I always say!" cried Lulu delightedly. "All women can't marry nowadays—there are not enough men to go
- 66. round. Besides, what is more contemptible than to see girls sitting idle, with their hands folded, waiting for somebody to come along and marry them? No, every girl ought to be able to earn her own living, and then she's safe, whatever happens!" Needless to say, such maxims would have been entirely abhorrent to Miss Waller, who regarded working-girls with detestation, as May well knew.
- 67. CHAPTER V. "A Beautiful Anomaly." Arrived at his rooms, Harold did the honours; not without fears lest May should miss the luxuries of her home. But she enjoyed the change of surroundings with all the zest of a schoolgirl, and Doris, being made much of, was as good as gold. Harold himself had not spent such a delightful hour since he came to Beachbourne, but his hour of bliss was all too short; for soon a summons came from a patient, and, though it was only a greengrocer in the next street, patients were too precious to be slighted. So he departed, begging Mrs. Burnside to remain with Lulu until his return. Left alone, the two girls settled down for a cosy chat; Doris being quite absorbed in an illustrated book Harold had produced picturing the wonders of the microscope. "Dear old Harold!" began his sister. "Don't think me silly, Mrs. Burnside, but I'm proud of him, knowing how hard he worked for his degree. Will he ever get a good practice here, do you think?" "I hope so; but it takes time," answered May, rather embarrassed. "Have you many brothers and sisters?" "There are six of us altogether—a formidable number, isn't it? But, I'm glad to say, we're all doing something, and don't cost dear old dad a penny. I remind Esther of that—she's my eldest sister—when she grumbles, and wishes we were back at Mallowfield Hall." "That was your father's place, wasn't it?" "Yes, our ancestors lived there centuries ago. This is the house." And she produced a photograph of an imposing mansion standing in a
- 68. spacious park, a residence which even Miss Waller would have acknowledged to be a magnificent property. "What a lovely place! And you had to leave it?" "He's not a gentleman," she said. —p. 401. "Yes, my grandfather was dreadfully extravagant, and since father came into power the agricultural depression was the finishing stroke. It was cruelly hard to leave the dear old place, but the mortgagees foreclosed, and we all had to turn out. Dad and mother went to live in Cornwall, where she owns a tiny cottage. Harold passed as a doctor, Jack's at Johannesburg, and Ted's in Australia. Then Connie, my youngest sister, is companion to an old lady, and Esther and I share a cupboard of a flat with an old schoolfellow, Mabel Bryan, whose partner I am in a typewriting office. Esther, who's awfully clever, as well as handsome, and knows several languages, is corresponding clerk to a firm of shippers. She gets a hundred a year,
- 69. and I manage to make about a pound a week; but I'm not clever, and have to do the best I can. We work awfully hard, but I really think we are happier than if we had nothing to do." "I'm sure you are," sighed May, as her eye fell upon her own dearly purchased finery. "I must say, I think it very plucky of you to take it as you do." Lulu opened her eyes, for she was not accustomed to pity. "I'm proud to be a working-woman, and even if I were rich like you, Mrs. Burnside, I couldn't bear to sit with my hands folded." "Rich like me!" May echoed drearily. "I'm not rich; I owe everything I possess to my aunt." "But she's rich, so it must be the same thing," persisted Lulu. Just then Harold came hurrying in. "I was as quick as I could be, Mrs. Burnside," he began, manifestly pleased to find May still there. With an alarmed glance at the clock, she arose to go, and said cordially— "I should be so pleased, Dr. Inglis, if you would bring your sister to see me on Tuesday afternoon." "Many thanks, Mrs. Burnside, but I must return by the excursion train on Tuesday morning," returned Lulu; and May dared not urge the point. To invite the Inglises to any meal but afternoon tea was out of her power, for Miss Waller disapproved of promiscuous guests at luncheon and dinner. So, bidding a cordial farewell to Lulu, May set forth with Doris to Victoria Square, escorted by happy Harold. "I call her a beautiful anomaly!" Lulu observed later on to her brother, when he asked what she thought of Mrs. Burnside. "At first, seeing how she was dressed, I concluded she was only a fashionable butterfly, caring for nothing but amusement. But from her talk I could see I had been unjust, and that there's nothing she would like better than being useful and independent. Poor thing! Her face is one of the saddest I ever saw."
- 70. "I believe she has a very uncomfortable time of it with Miss Waller, who is a Tartar, from all accounts." "Then why does she stay with her?" "What else can she do, with that child?" An unpleasant quarter of an hour awaited May within her aunt's door, which she entered with a sinking heart. Doris was instantly bundled off to bed, after which Miss Waller—in thin, high tones, very different from her suave society accents—moralised on May's enormities in absenting herself without notice, whilst Mr. Lang vainly awaited her return. He had just gone, evidently vexed at her non- appearance. "Mr. Lang has no jurisdiction over me!" May was irritated into retorting at last, whereupon her aunt's frown became portentous. "Mr. Lang is my friend, and, as such, I insist that you treat him with respect! Pray, who are you, to set your will against mine? I paid for the very dress you have on, and every article you possess, and but for me you and Doris would be in the workhouse!" May would not trust herself to reply, but went away to her own room, there to shed some very bitter tears. As she eyed her tall figure in the glass, arrayed in the beautiful garments for which she had to pay so dearly, she heartily envied the three happy girls in their flat, as described by Lulu. How fortunate they were, to be able to do as they pleased, and indebted to no living soul for anything! "Oh, to be free!—to be free!" she panted, realising her slavery as she had never realised it before.
- 71. CHAPTER VI. Bijou's Mistress. When bright-faced Lulu had returned home, brief though her visit had been, Harold missed her inexpressibly. To vary the monotony of his dreary rooms, he paid his promised call in Victoria Square, to find himself promptly relegated to the background by Miss Waller, who perfectly understood how to snub people without being unladylike. May, who made tea, hardly uttered a word; and the lion of the occasion was Mr. Lang, who expatiated on the riches of South Africa and his own importance on the Randt. "You're nowhere unless you've got money nowadays," he confidently asserted. "Oh, but"—expostulated a meek little clergyman's wife, looking rather shocked, "surely culture goes for something—and descent— and——" "Culture, descent, my dear madam! We haven't time to bother about such things at Johannesburg! They'd be no use to a man there!" "I'm sorry to hear it," Harold was provoked into saying. "My brother Jack is out there, and I shouldn't like him to come back less of a gentleman than he went!" "What's he doing?" disdainfully drawled the plutocrat. "He is in the office of the Victorina Mine." "Ah! a good property that—not equal to the Springkloof, though. I know the Victorina manager; perhaps next time I go out, I may look your brother up."
- 72. "How kind of you, Mr. Lang!" gushed Miss Waller; but Harold never said a word. "Well now, Miss Waller," said Mr. Lang, "it's time I was returning to London, and don't you think you ought to give Mrs. Burnside a little taste of dissipation before the season closes?" "I should have taken her to London before, but dear May always says she doesn't like town," answered the spinster, who always posed as a most affectionate aunt in public. "I must leave you to try your persuasions." As she spoke, she darted a glance at her niece which plainly said, "Refuse to go, if you dare!" "London is so hot now—and Doris——" faltered the girl in manifest dismay. The clergyman's wife took her departure, but Harold sat doggedly on, determined to hear the result. "Doris could be left behind perfectly well," rejoined Mr. Lang, who disliked the child as much as she disliked him. "We shall be very pleased to see a little of London under your auspices, Mr. Lang," interrupted Miss Waller, in a sub-acid tone. "I know of some nice rooms near Hyde Park, which will be quieter than a hotel, and I'll write about them to-night." May said no more; but Harold perceived an expression of absolute despair flit over her features for a moment, and his heart swelled with pity for her. He paced his lonely sitting-room many times that evening, lamenting his own impotence. A few patients, poor people to whom he was at home for an hour, mornings and evenings, came to consult him for a fee of one shilling, medicine included; but even these were few in number. He had the very deepest sympathy with the poor; but to be wasting his time here when, in a few days, Mrs. Burnside would be staying close to that man in Palace Gardens!
- 73. "Harold! Here's that pretty girl in grey."—p. 402. There was a ring at the bell, and the landlady entered, announcing, with a smile, "Miss Geare and Miss Pepper." A little, round-faced, white-haired lady, with curiously wandering light-blue eyes, then tripped into the room, carrying something carefully in her arms; followed by a forbidding, tall, dark-haired female, to whom Harold took an instant and hearty dislike. "Oh, doctor!" began the little lady, in a breathless, excited way, with hardly any stops, "I saw your plate on the door, and I've come to see if you can cure my darling little Bijon; a great cruel cabman has just driven over him, and I'm afraid his poor leg's broken. Will you look?" Harold could hardly restrain a smile. "I am not a veterinary surgeon, madam."
- 74. Harold perceived an expression of despair flit over her features.—p. 405. "I told you it was no use coming here," growled Miss Pepper, the companion, in a voice as unamiable as her face. "Oh, but poor Bijou is in such pain!" With that Miss Geare burst into passionate tears and again entreated Harold's aid. To end the tiresome scene, he examined the dog, unprofessional though it might be, and, finding one of its legs was broken, improvised splints and set it carefully. Miss Geare's gratitude was excessive. "And you will come and see Bijou, won't you?" implored the old lady. "He must have attention until he gets well, and I live at Lyndhurst Lodge, Murray Road."
- 75. Harold demurred, as being unprofessional. "Then come to attend me," eagerly responded Miss Geare. "I'm often rather ailing; and you can give Bijou a look at the same time." She looked at him so pleadingly that he could not find it in his heart to say no. She brightened up at his consent, and asked for a cab, in which to take home her injured darling, and then laid a sovereign and a shilling on the table. "I don't think I am entitled to charge for attending the dog," said Harold, crimsoning. "Certainly, this is far too much." "Watson, the veterinary surgeon, never would have charged a guinea," indignantly added Miss Pepper; but Miss Geare was resolute, and when she had departed, it was certainly pleasant to see the gold piece on the table, sovereigns being sadly scarce with him, poor fellow! He instituted inquiries, and learnt that Miss Geare belonged to a good family, and was well-off, but somewhat "queer." In early youth she was engaged to an officer, who was killed at Delhi, and had become gradually more and more eccentric, until now she only lived for her dogs and cats. Miss Pepper, it was added, tyrannised over her shamefully, as though she were the mistress and Miss Geare the companion. The old lady was warm-hearted, though rather fickle, and, having taken a fancy to Harold, contrived to secure him several fresh and welcome patients. Miss Geare herself was far from strong, and afforded a legitimate exercise for Harold's skill, which salved his conscience in the matter of Bijou. But Miss Pepper remained, from first to last, distinctly hostile. [END OF CHAPTER SIX.]
- 76. CHILDISH MEMORIES OF LEWIS CARROLL. By One of his Alices. So many children will grieve over the sad event—the death that deprived them of one of the best and kindest friends that children ever came across—the children who have followed "Alice" through all the wonderful adventures of "Wonderland" will be saddened by the thought that the hand which held the pen that gave them such amusement is now still for ever; and the children now grown up who knew Lewis Carroll personally will look back into the years agone and remember his delightful stories, and his never-ceasing kindness towards them in their youthful days. LEWIS CARROLL . (At the age of 8.) To my mind Oxford will never be quite the same again, now that so many of the dear old friends of one's childhood have "gone over to the great majority." My poor old father, though always wishing to go
- 77. for little excursions back to the old University town where so many years of his life had been spent, came back to his country rectory in the Cotswold Hills bemoaning the loss of the "many who had gone before," and how the familiar forms of his old college friends were, alas! no more to be seen. Often, in the twilight, when the flickering firelight danced on the old wainscoted wall, have we—father and I—chatted over the old Oxford days and friends, and the merry times we all had together in Long- Wall Street. I was a nervous, thin, remarkably ugly child, and, for some years, I might say, I was quite alone in the nursery, my small, fat baby-brother being much more appreciated than myself. I was left almost entirely to the kind and gentle mercy of Mary Pearson, my own particular attendant, and though father, of course, had commenced his friendship with Mr. Dodgson (Lewis Carroll) long before, I only remember him first when I was about seven, and from that time until we went to live in Gloucestershire, he was one of my most delightful friends.
- 78. (From a Photo by Lewis Carroll.) THE AUTHOR AND HER FATHER (THE REV. E. A. LITTON). I shall never forget when, sitting on a rustic seat with Mr. Dodgson under a dear old tree in the Botanical Gardens, I heard for the first time the delightful and ever-entertaining story of Hans Andersen's "Ugly Duckling." I was devoted to books, and could read quite well for so small a child, but I cannot explain the delightful way in which
- 79. Mr. Dodgson read and told his stories: as he read, the characters were real flesh and blood—living figures. This particular story made a great impression on me, and, being very sensitive about my ugly little self, it greatly interested me. I remember his impressing upon me that it was better to be good, truthful, and to try not to think of self, than to be a pretty, selfish child, spoilt and disagreeable, and he, from that story, gave me the name of "Ducky," which name clung to me for many years; in fact, from that day Mary Pearson always called me "Miss Ducky." (From a Photo by Lewis Carroll.) THE ORIGINAL OF "ALICE IN WONDERLAND." Many a time has Mr. Dodgson said, "Never mind, little Ducky; perhaps some day you will turn out a swan." I always attribute my love for animals to the teaching of Mr. Dodgson: his stories of animal life, his knowledge of their lives and histories, his enthusiasm about birds and butterflies, passed many a tiresome hour away. The monkeys in the Botanical Gardens were our special pets, and, oh! the nuts and biscuits we used to give them! He entered into the spirit of the fun as much as "Ducky" did.
- 80. Then there were the mornings spent in the Christ Church and Merton meadows: Mary and I took our daily walks abroad there. Years have passed since then, and I have travelled in many climes, but I always think that the recollections of the days of one's childhood never fade. One's views of life, persons, and things were so fresh, so different from the judgment of things in later years. Those meadows were, to me, full of the loveliest field-flowers— daisies, the beautiful "snake-flower"—so rare, I understand now— the golden buttercups, the masses of dandelions with the added, never-failing fun of blowing the downy seeds away. Nurse Mary always took thread and a needle in her pocket; these were for the making of daisy-chains, and, oh! the wreaths we strung as we sat in the soft grass, with the dear old Broad Walk quite close, and when we raised our eyes the lovely vision of Merton College, with its covered walls of Virginian creeper! It all comes back to me so vividly, though it is now far away in the past years. And how delighted we were to see the well-known figure in his cap and gown coming, so swiftly, with his kind smile ready to welcome the "Ugly Duckling" sitting in the grass! I knew, as he sat beside me, that a fairy-tale book was hidden in his pocket, or that I should hear something nice—perhaps a new game or a puzzle—and he would gravely accept a tiny daisy bouquet for his coat with as much courtesy as if it had been the finest hot-house boutonnière. I was very proud when, between us, we had made a chain of cuckoo- flowers and daisy heads long enough to twine round my hat. These meadows and the walk along the wall were remarkable then for the quantity of snails of all kinds that, on fine days and damp days, came out to take the air, and to me they were objects of great dislike and horror. Mr. Dodgson so gently and patiently showed me how silly I was, how harmless the poor snails were, and told me so much about the shells they carried on their backs, and showed me how wonderfully they were made, that I soon got over the fright and made quite a collection of discarded shells; which collection finally
- 81. took up its abode in a little crimson-paper trunk that Mr. Dodgson found at old Mrs. Green's toyshop and bought for me. About this time also father had added to my nursery literature "Ministering Children," "Sandford and Merton," and "Rosamund; or, The Purple Jar." All these were shown in great glee to my kind friend, who (as I knew he would) read to me from them. Two or three times I went fishing with him from the bank, near the Old Mill opposite Addison's Walk (Oxford), and he entered quite into my happiness when a small fish came wriggling up on the end of my crooked pin and line, just ready for the dinner of the little white kitten, "Lily," he had given me. In those days Addison's Walk had, in season, its banks covered with pretty periwinkles—white and blue—and there were strict laws not to pick them. I, childlike, could not resist the temptation, and one day, Mary being seated at work near by, "Ducky," left to play alone, gathered a bunch of the coveted beauties, hid them under her little spencer (a small coat of those days), and trotted by Mary's side, half-frightened, to the lodge of the gruff old porter, who sat reading his paper, glancing always at the passers through his doorway. Nothing escaped his notice. Mary went through and then I, half- trembling, with the periwinkles closely clasped to my side. The street gained, I was safe, but (alas! there is always a "but"), Mr. Dodgson, going to see a friend in the college, came up to me, saying, "Why so flushed, little Alice? And what is that hanging below your jacket?" The flowers had not gained anything by their hot pressure under my jacket, and it was a very much ashamed, sad little girl who stood convicted of flower-theft! "Ducky, come with me"; and, taking my unwilling hand, he led me back to the grim old custodian of the cloisters, to whom I had to deliver up the now faded periwinkles, and promise future goodness and "never to do so any more." Then Mary took me in hand, and the quiet little "weep" I indulged in while going home was much enhanced by the sound of Mary's voice telling me: "Miss Ducky, you
- 82. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com