Chapter 29

Web Engineering

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
 Attributes of
Web-Based Applications
Network intensive. By its nature, a WebApp is
network intensive. It resides on a network and
must serve the needs of a diverse community
of clients.
Content-Driven. In many cases, the primary
function of a WebApp is to use hypermedia to
present text, graphics, audio, and video
content to the end-user.
Continuous evolution. Unlike conventional
application software that evolves over a series
of planned, chronologically-spaced releases,
Web applications evolve continuously.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
2
 WebApp Characteristics
Immediacy. Web-based applications have an
immediacy [NOR99] that is not found in any other
type of software. That is, the time to market for a
complete Web-site can be a matter of a few days or
weeks.
Security. 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 application itself.
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,
aesthetics may have as much to do with success as
technical design.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
3
 WebApp Quality Factors

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
4
 The WebE Process

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
5
 Formulation
 Allows the customer and developer to establish a
common set of goals
 Address three questions:
 What is the main motivation for the WebApp?
 Why is the WebApp needed?
 Who will use the WebApp?
 Defines two categories of goals”
 Informational goals—indicate an intention to provide specific
content and/or information the the end user
 Applicative goals—indicate the ability to perform some task
within the WebApp

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
6
 Analysis for WebE
Content Analysis. The full spectrum of content to be
provided by the WebApp is identified, including text,
graphics and images, video, and audio data. Data
modeling can be used to identify and describe each of
the data objects.
Interaction Analysis. The manner in which the user
interacts with the WebApp is described in detail. Use-
cases can be developed to provide detailed
descriptions of this interaction.
Functional Analysis. The usage scenarios (use-cases)
created as part of interaction analysis define the
operations that will be applied to WebApp content and
imply other processing functions. All operations and
functions are described in detail.
Configuration Analysis. The environment and
infrastructure in which the WebApp resides are
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
described in detail. 7
 Design for WebE
 Architectural design — laying out the page
structure of the WebApp
 Navigation design — defining the manner in which
pages will be navigated
 Interface design — establishing consistent and
effective user interaction mechanisms

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
8
 Architectural Styles

Linear
structure Grid
structure

Network
Hierarchical
structure
structure

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
9
 Navigation Design
 identify the semantics of navigation for different
users of the site
 User roles must be defined
 Semantics of navigation for each role must be identified
 A semantic navigation unit (SNU) should be defined for each
goal associated with each user
 Ways of navigating (WoN) are defined
 define the mechanics (syntax) of achieving the
navigation
 options are text-based links, icons, buttons and switches, and
graphical metaphors

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
10
 Interface Design Guidelines
• Server errors, even minor ones, are likely to cause a user to
leave the Web site and look elsewhere for information or
services.
• Reading speed on a computer monitor is approximately 25
percent slower than reading speed for hardcopy. Therefore,
do not force the user to read voluminous amounts of text.
• Avoid “under construction” signs—they raise expectations
and cause an unnecessary link that is sure to disappoint.
• Users prefer not to scroll. Important information should be
placed within the dimensions of a typical browser window.
• Navigation menus and headbars should be designed
consistently and should be available on all pages that are
available to the user. The design should not rely on browser
functions to assist in navigation.
• Aesthetics should never supersede functionality.
• Navigation options should be obvious, even to the casual
user. The user should have to search the screen to determine
how to link
These courseware toareother
materials to be used incontent
conjunction withor services.
Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
11
 Testing for WebE – I
1. The content model for the WebApp is reviewed to uncover
errors. This ‘testing’ activity is similar in many respects to
copy-editing for a written document.
2. The design model for the WebApp is reviewed to uncover
navigation errors. Use-cases, derived as part of the analysis
activity, allow a Web engineer to exercise each usage
scenario against the architectural and navigation design.
3. Selected processing components and Web pages are unit
tested. When WebApps are considered, the concept of the
unit changes. Each Web page encapsulates content,
navigation links and processing elements (forms, scripts,
applets).
4. The architecture is constructed and integration tests are
conducted. The strategy for integration testing depends on
the architecture that has been chosen
• a linear, grid, or simple hierarchical structure—integration is
similar to conventional software
• mixed hierarchy or network (Web) architecture — integration
testing
These ismaterials
courseware similar are to to the
be used approach
in conjunction used
with Software for OO
Engineering: systems.
A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
12
 Testing for WebApps – II
5. The assembled WebApp is tested for overall functionality and
content delivery. Like conventional validation, the validation of
Web-based systems and applications focuses on user visible
actions and user recognizable outputs from the system.
6. The WebApp is implemented in a variety of different
environmental configurations and is tested for compatibility with
each configuration. A cross reference matrix the defines all
probable operating systems, browsers, hardware platforms, and
communications protocols is created. Tests are then conducted
to uncover errors associated with each possible configuration.
7. The WebApp is tested by a controlled and monitored
population of end-users. A population of users that encompasses
every possible user role is chosen. The WebApp is exercised by
these users and the results of their interaction with the system
are evaluated for content and navigation errors, usability
concerns, compatibility concerns, and WebApp reliability and
performance.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
13
 Project Management for WebE
 Initiate the project
 Many of the analysis activities should be performed internally
even if the project is outsourced
 A rough design for the WebApp should be developed internally.
 A rough project schedule, including not only final delivery
dates, but also milestone dates should be developed.
 The degree of oversight and interaction by the contractor with
the vendor should be identified.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
14
 Project Management for WebE
 Select candidate outsourcing vendors
 interview past clients to determine the Web vendor’s
professionalism, ability to meet schedule and cost commitments,
and ability to communicate effectively:
 determine the name of the vendor’s chief Web engineer(s) for
successful past projects (and later, be certain that this person is
contractually obligated to be involved in your project
 carefully examine samples of the vendor’s work that are similar
in look and feel (and business area) to the WebApp that is to be
contracted.

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
15
 Project Management for WebE
 Assess the validity of price quotes and the
reliability of estimates
 Does the quoted cost of the WebApp provide a direct or indirect
return-on-investment that justifies the project?
 Does the vendor that has provided the quote exhibit the
professionalism and experience we require?
 Establish the degree of project management
expected from both parties
 Assess the development schedule
 WBS should have high granularity
 Milestones should be defined at tight intervals

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
16
 SCM for WebE
 WebApp content is extremely varied
 SCO’s must be defined
 The “longevity of the SCO must be identified
 Many different people participate in content
creation
 Determine who “owns” the WebApp
 Establish who can make changes and who approves them
 Manage scale
 As a small WebApp grows, the impact of an seemingly
insignificant change can be magnified

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
17