Chapter 17

Formulation and Planning

for
Web Engineering
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman

1
Formulation
 begins with the identification of business need
 moves into a description of WebApp objectives
 defines major features and functions
 establishes a requirements gathering activity that will
lead to the development of an analysis model
 allows stakeholders and the web engineering team to
establish a common set of goals and objectives for
the construction of the WebApp.
 identifies the scope of the development effort
 provides a means for determining a successful, outcome..

2
Formulation Questions
 What is the main motivation (business need) for the
WebApp?
 What are the objectives that the WebApp must fulfill?
 Who will use the WebApp?
 Answers provide …
 Informational goals—indicate an intention to provide
specific content and/or information for the end-user
 Applicative goals—indicate the ability to perform
some task within the WebApp

3
WebE Requirements Gathering
 Ask stakeholders to define user categories and
develop descriptions for each category
 Communicate with stakeholders to define basic
WebApp requirements
 Analyze information gathered and use
information to follow-up with stakeholders
 Define use-cases (Chapter 8) that describe
interaction scenarios for each user class
4
Defining User Categories
 What is the user’s overall objective when using
the WebApp?
 What is the user’s background and
sophistication relative to the content and
functionality of the WebApp?
 How will the use arrive at the WebApp?
 What generic WebApp characteristics does the
user like/dislike?
5
Communicating with
Stakeholders
 Traditional focus groups—a trained moderator meets with a
small group of representative end-users (or internal
stakeholders playing the role of end-users).
 Electronic focus groups—a moderated electronic discussion
conducted with a group of representative end-users and
stakeholders.
 Iterative surveys—a series of brief surveys, addressed to
representative users and requesting answers to specific
questions about the WebApp
 Exploratory surveys—a Web-based survey that is tied to one or
more WebApps that have users who are similar to the ones that
will use the WebApp to be developed.
 Scenario-building—selected user are asked to create informal
use-cases that describe specific interactions with the WebApp.
6
Preliminary Analysis
 Categorize information gathered by user
class and transaction type
 Develop lists of …
 content objects
 operations that are applied to content objects
within a specific user transaction
 functions (e.g., informational, computational,
logical, and help-oriented) that the WebApp
provides for end-users
 other non-functional requirements that are noted
during the communication activities. 7
Use-Cases
 Provide the detail necessary to create an
effective analysis model
 Help the developer to understand how users
perceive their interaction with the WebApp
 Use-cases help to compartmentalize Web
engineering work
 Use-cases provide important guidance for
those who must test the WebApp
8
Project Differences
Traditional Projects small e-Projects major e-Projects
Requirements Rigorous Limited Rigorous
Gathering
Technical Robust: models, spec Descriptive overview robust: UML models,
Specifications spec

Project Duration Measured in months or Measured in days, Measured in

years weeks or months months or years
Testing and QA Focused on achieving Focused on risk control SQAas described
quality tar- in Chapter 26
gets
Risk Management Explicit Inherent Explicit
Half-life of 18 months or longer 3 to 6 months or 6 to 12 months
deliverables shorter or shorter

Release Process Rigorous Expedited Rigorous

Post-release customer Requires proactive Automatically Obtained both auto-
feedback effort obtained from user matically and via
interaction solicited feedback

9
The WebE Team
 WebE team roles
 Content Developer/Providers
 Web Publisher
 Web Engineer.
 Business domain experts
 Support Specialist
 Administrator (a.k.a. “Web Master”)
10
Outsourcing vs. In-house

We b We b
e n g in e e rs s u p p o rt e n g in e e rs
s u p p o rt
s p e cialis t s s p e cialis t s

Co n t e n t v e n d o r liais o n
Co n t e n t
d e v e lo p e rs d e v e lo p e rs
ad min is t rat o r ad m in is t rat o r
o u t s o u rcin g
ve ndor
We b We b
p u b lis h e r p u b lis h e r
b u s in e s s b u s in e ss
man ag e rs man ag e rs
s t ake h o ld e rs s t ake h o ld e rs

m arke t in g m arke t in g
e n d -u s e rs & e n d -u s e rs &
s ale s s ale s

(a) in-h o us e d e ve lo p m e nt (a) out s ource d d e ve lo pm e n t

11
WebApp Outsourcing - I
 Initiate the project by performing the following tasks internally
 Gather requirements
 Develop a “rough design”
 Develop a rough schedule with delivery dates
 Consider increments
 Make a list of responsibilities
 For in-house staff
 For outsourcing vendor
 Define liaison mechanisms

12
WebApp Outsourcing - II
 Select Candidate Outsourcing Vendors
 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?
 Understand the Degree of Project Management You
Can Expect/Perform
 Assess the Development Schedule
 Manage Scope
13
WebApp Planning - In-House
 Understand scope, the dimensions of change, and
project constraints
 Define an incremental project strategy
 Perform risk analysis
 Develop a quick estimate
 Select a task set (process description)
 Establish a schedule
 Define project tracking mechanisms
 Establish a change management approach

14
WebE “Worst Practices”
 We have a great idea, so lets begin building the
WebApp—now.
 Stuff will change constantly, so there’s no point in
trying to understand WebApp requirements.
 Developers whose dominant experience has been in
traditional software development can develop
WebApps immediately. No new training is required.
 Be bureaucratic.
 Testing? Why bother?
15