Software Engineering: A Practitioner's Approach, 6/e

Part 3
R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. This presentation, slides, or hardcopy may NOT be used for short courses, industry seminars, or consulting purposes.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and  are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

 Supplementary Slides for

copyright © 1996, 2001, 2005

1

Software Engineering: A Practitioner’s Approach,  6/e

Chapter 16 Web Engineering
copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

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

2

Web Applications

WebApps encompass: WebApps 

complete Web sites
 

Simple information Web sites Complex e­Commerce of other sites with embedded functionality  and data retrieval Complex Web sites that are interoperable with other legacy  software and systems

 

 specialized functionality within Web sites  information processing applications that reside on the Internet  or on an intranet or ExtraNet.

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

3

WebApp Attributes—I
 

 

Network intensiveness.  A WebApp resides on a network  and must serve the needs of a diverse community of clients.  Concurrency.  A large number of users may access the  WebApp at one time;  patterns of usage among end­users will  vary greatly. Unpredictable load. The number of users of the WebApp  may vary by orders of magnitude from day to day.  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. 

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

4

WebApp Attributes—II

Availability.  Although expectation of 100 percent availability is  unreasonable, users of popular WebApps often demand access  on a “24/7/365” basis.   Data driven.  The primary function of many WebApps is to use  hypermedia to present text, graphics, audio, and video content  to the end­user.  Content sensitive.  The quality and aesthetic nature of content  remains an important determinant of the quality of a WebApp.  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, 6/e and  are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

5

WebApp Attributes—III

Immediacy. WebApps often exhibit a time to market that can be a  matter of a few days or weeks. 

With modern tools, sophisticated Web pages can be produced in only a  few hours.

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. 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, 6/e and  are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

6

WebApp Categories
         

informational—read­only content is provided with simple navigation and links download—a user downloads information from the appropriate server customizable—the user customizes content to specific needs interaction—communication among a community of users occurs via chatroom,  bulletin boards, or instant messaging user input—forms­based input is the primary mechanism for communicating need transaction­oriented—the user makes a request (e.g., places an order) that is fulfilled by  the WebApp service­oriented—the application provides a service to the user, e.g., assists the user in  determining a mortgage payment Portal—the application channels the user to other Web content or services outside the  domain of the portal application database access—the user queries a large database and extracts information data warehousing—the user queries a collection of large databases and extracts  information

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

7

Web Engineering
“Web development is an adolescent … Like most  adolescents, it wants to be accepted as an adult  as it tries to pull away from its parents. If it is  going to reach its full potential, it must take a  few lessons from the more seasoned world of  software development.”  Doug Wallace et al

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

8

The WebE Process
Must accommodate:
  

Incremental delivery Frequent changes Short timeline An incremental process model (Chapters 3 and  4) should be used in virtually all situations An agile process model (Chapter) is appropriate  in many situations

Therefore,
 

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

9

The WebE Process
acceptance test custom use er custom evaluation er Release so a in mn ftw re cre e t coding com ponent test

refactoring

design m odel analysis m odel business analysis form ulation
content iteration function configuration content architecture navigation interface

iteration plan

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

10

The WebE Process Framework—I

Customer communication
 

Business analysis defines the business/organizational context for  the WebApp. Formulation is a requirements gathering activity involving all  stakeholders. The intent is to describe the problem that the  WebApp is to solve The “plan” consists of a task definition and a timeline schedule  for the time period (usually measured in weeks) projected for  the development of the WebApp increment.

Planning

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

11

The WebE Process Framework—II

Modeling

Analysis model—establishes a basis for design
   

Content Analysis.  Interaction Analysis.  Functional Analysis.  Configuration Analysis.  Content design Aesthetic design Architectural design  Interface design  Navigation design Component design 

Design model—represents key WebApp elements
     

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

12

The WebE Process Framework—III

Construction
 

WebE tools and technology are applied to construct the  WebApp that has been modeled Testing of all design elements configure for its operational environment deliver to end­users, and Evaluation feedback is presented to the WebE team  the increment is modified as required (the beginning of the next  incremental cycle)  

Delivery and Evaluation (Deployment)
   

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

13

WebE—Basic Questions
 

     

How important is a Web site home page?  What is the most effective page layout (e.g., menu on top, on the right or  left?) and does it vary depending upon the type of WebApp being  developed? Which media options have the most impact?  How much work can we expect a user to do when he or she is looking for  information?  How important are navigational aids when WebApps are complex? How complex can forms input be before it becomes irritating for the user?  How can forms input be expedited? How important are search capabilities?  Will the WebApp be designed in a manner that makes it accessible to  those who have physical or other disabilities? Susan Weinshenk
14

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

WebE—Best Practices
 

   

Take the time to understand the business needs and product  objectives, even if the details of the WebApp are vague. Describe how users will interact with the WebApp using a scenario­ based approach Develop a project plan, even it its very brief. Spend some time modeling what it is that you’re going to build.  Review the models for consistency and quality.  Use tools and technology that enable you to construct the system  with as many reusable components as possible.  Don’t rely on early users to debug the WebApp—design  comprehensive tests and execute them before releasing the system.
15

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

Software Engineering: A Practitioner’s Approach, 6/e

Chapter 17 Formulation and Planning Web Engineering
copyright © 1996, 2001, 2005

for

R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and  are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

16

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..

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

17

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

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

18

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

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

19

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?

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

20

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.

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

21

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.

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

22

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

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

23

The WebE Team

WebE team roles
     

Content Developer/Providers Web Publisher Web Engineer.  Business domain experts Support Specialist Administrator (a.k.a. “Web Master”)

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

24

Project Differences
Requirements Gathering Technical Specifications Project Duration Testing and QA Risk Management Half­life of deliverables Traditional Projects Rigorous Robust: m odels, spec small e­Projects Lim ited Descriptive overview major e­Projects Rigorous robust: UML m odels, spec Measured in m onths or years

Measured in m onths or Measured in days, years weeks or m onths Focused on achieving quality tar­ gets Explicit 18 m onths or longer

Focused on risk control SQA  as described in Chapter 26 Inherent 3 to 6 m onths or shorter Expedited Autom atically obtained from  user interaction Explicit 6 to 12 m onths or shorter Rigorous Obtained both auto ­ m atically and via solicited feedback

Release Process Rigorous Post­release customer Requires proactive feedback effort

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

25

Outsourcing vs. In­house
support specia lists Web engineers Content developers a inistra dm tor a inistra dm tor outsourcing vendor business m na a gers sta keholders m rketing a & sa les Web publisher business m na a gers sta keholders m rketing a & sa les Web publisher support specia lists Web engineers vendor lia ison Content developers

end-users

end-users

(a) in-house developm ent

(a) outsourceddevelopm ent

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

26

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 For in­house staff For outsourcing vendor

Make a list of responsibilities
 

Define liaison mechanisms

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

27

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

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

28

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
29

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

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?
30

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

Software Engineering: A Practitioner’s Approach,  6/e

Chapter 18 Analysis Modeling for WebApps
copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

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

31

Analysis
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 described in detail. 
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and  are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

32

When Do We Perform Analysis?

In some WebE situations, analysis and design merge.  However, an explicit analysis activity occurs when …
   

the WebApp to be built is large and/or complex the number of stakeholders is large the number of Web engineers and other contributors is large the goals and objectives (determined during formulation) for the  WebApp will effect the business’ bottom line the success of the WebApp will have a strong bearing on the  success of the business

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

33

The User Hierarchy
Sa feHom eAssured.com user

guest

registered user

custom service er sta ff

new custom er

existing custom er

Figure 18.1 U hierarchy for SafeHom ser eAssured.com
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and  are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

34

Use­Case Diagram
ds r e ecib hmlaot o e yu pr s eue ds r tiv ecip e cn n otet
<in lu e > <c d >

c s me uto iz Sfeo e a Hm

<in lu e > <c d > <in lu e > <c d >

s let ec Sfeo e a Hm c mnn o p ets o

sv ae c n ua n ofigr tio c s ma nfuc nlity uto iz tio ntioa lo-into g Sfeo e s ue. o a Hm s r d m A c
<in lu e > <c d >

vw ie s op gc r hpin at poid rve pr hs dta uc ae a

nw uto e e cs m r r c lls vd ea ae c n ua n ofigr tio

pr hs uc ae c n ua n ofigr tio

<in lu e > <c d >

<in lu e > <c d >

c m te op le Sfeo eodr a Hm r e e o mc fuc nlity -c me e ntioa r

F u 1 .2 Ue aed g m rn w uto e ig re 8 s -c s ia ra fo e -c s mr

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

35

Refining the Use­Case Model
 

Use­cases are organized into functional packages Each package is assessed [CON00] to ensure that it is:
  

Comprehensible—all stakeholders understand the purpose of the package Cohesive—the package addresses functions that are closely related to  one another Loosely coupled—functions or classes within the package collaborate  with one another, but collaboration outside the package are kept to a  minimum. Hierarchically shallow—deep functional hierarchies are difficult to navigate and hard for end-users to understand; therefore, the number of levels within a use-case hierarchy should be minimized whenever possible.

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

36

The Content Model

Content objects are extracted from use-cases

examine the scenario description for direct and indirect references to content

 

Attributes of each content object are identified The relationships among content objects and/or the  hierarchy of content maintained by a WebApp
 

Relationships—entity­relationship diagram or UML Hierarchy—data tree or UML

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

37

Data Tree
M rke g e tio a tin D scrip n Po g p h to ra h T ch e tio e D scrip n S ea ch mtic Vid o e p rtN me a u br p rtN m a ae co p n n mo e t p rtT e a yp d scrip n e tio p rice W o sa P h le le rice R ta rice e ilP

Fig re 18.3 D tree for a afeH ecom on t u ata S om p en

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

38

Analysis Classes

Analysis classes are derived by examining each use-case A grammatical parse is used to identify candidate classes A UML class diagram is developed for each analysis class

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

39

Analysis Class Example
BillOfM teria a ls ProductCom ponent pa rtNum ber pa m rtNa e pa rtType description price crea teNew () Item getDescription () getTechSpec 1 identifier priceTota l a ddEntry () deleteEntry () editEntry () na e() m sa ve() com putePrice () 1

*
Sensor Ca era m ControlPa nel SoftFea ture

*
BoM Item qua ntity price a ddtoList() deletefrom List()

Figure 18.4 Analysis classes for use-case: select SafeHom com e ponents

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

40

The Interaction Model

Composed of four elements:
use-cases  sequence diagrams  state diagrams  a user interface prototype Each of these is an important UML notation and has  been described in Chapter 8

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

41

Sequence Diagram
:R o om nwc s mr e uto e
describes room *

:Flo rP n o la

:P d ct ro u Co p n n mo e t

:Billo f M te ls a ria

Flo rP n o la R p sito e o ry

Bo M R p sito e o ry

places room in floor plan

save floor plan configuration

selects product com ponent* add to B oM

save bill of m aterials

Figure 18.5 Sequence diagramfor use-case:select SafeHom com e ponents

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

42

State Diagram
Vlidtin ue a a g sr ueid sr ss mta sÒptr ay yte s tu= u edÓ in vlidte aad sletÒg Ó dp y s =ete sr Ó e c lo-in islam Ò r eid g nu dp y s =n r s d islam ÒtepwÓ ge pswr vlidte as od a a d etr / lo-inr qete n y g eus d nw s m e c to e u r d:r nue vlidtio o u sr a a n eit/stue acs s itc x e sr ces w h c s ma nc m te uto iz tio o p le Sletin ue atio e c g sr c n sleto e fuc n e c thr ntios ss mta sÒkr ay yte s tu= edÓ lin dp ynv a ncoeÓ isla: aigtio hics etr / vlidte ue n y a a d sr d:lin a r qir d o k s eue eit/ue atio slete x sr c n e c d

slete o mc (pr hs)fuc nlity e c -c me e uc ae ntioa r sletc s ma n ntioa e c uto iz tio fuc nlity Sv gflorp n ain o la ss mta sÒptr ay yte s tu= u edÓ in dp ys r g inicto isla: toae da r etr / florp nsv slete n y o la ae e c d d:s r florp n o toe o la eit/sv cm te x ae o p d le

nxsletio et e c n sletdsr tiv e c ecip e Cs min uto iz g cn n otet sletdsr tiv e c ecip e ss mta sÒptr ay yte s tu= u edÓ in Dfin gr o e in om cn n otet dp ybs intr c n isla: aic s utios r o bin dfind ss mta sÒptr ay ome g e e yte s tu= u edÓ in dp yr odf.wdw isla: om ino e etr /vlidte ue n y a a d sr d:poesue sletio o r cs sr e c n etr / r o df.slete n y om e c d e eit/cs ma n r inte x uto iz tio tema d a r o s d:r nr o qeie ll om o u omur s dfind d:s r r o vr b s e e o toe omaiale eit/r o cm te x omo p d le sletsv florp n e c ae o la sletete r o inflorp n e c n r om o la

r o inetio cm te omsr n o p d le

sletdsr tiv e c ecip e Bild gflorp n u in o la cn n otet ss mta sÒptr ay yte s tu= u edÓ in dp yflorp nwdw isla: o la ino etr / florp nslete n y o la e c d d:inetr o inp c o sr om lae d:s r florp nvr b s o toe o la aiale eit/r o inetio cm te x omsr n o p d le

F u 1 .6 P rtia sta d g m r n wcu mr ra tio ig re 8 a l te ia ra fo e sto ete c n in

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

43

The Functional Model

The functional model addresses two processing elements  of the WebApp
 

 user observable functionality that is delivered by the WebApp  to end­users  the operations contained within analysis classes that implement  behaviors associated with the class. 

An activity diagram can be used to represent processing  flow

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

44

Activity Diagram
iniaz to lCs it li e ta ot
n c mnn r m o o L t o o p ets e a n Mis o in B c mnn r m oBMis o p ets e a no L t o in

inoe vk clchpg ot aSipinCs rtu s er : n sipinCs hpg ot inoe vk dtemDcut e r in ison e rtu s dcut e r : ison n
dc ut> ison 0 dc ut<0 ison =

gtpc ad e r en i qatity un linCs = eot pc xqatity r e un i adlinCs to d eot to lCs ta ot to lCs= ta ot to lCs -dcut ta ot ison

taTta xo l= to lCs x xa ta ot tarte pcTta r eo l= i to lCs + xo l ta ot taTta +hpg ot sipinCs

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

F u 1 .7 A tiv d g m r co p te rice p ra n ig re 8 c ity ia ra fo mu P () o e tio

45

The Configuration Model

Server­side

Server hardware and operating system environment must be  specified Interoperability considerations on the server­side must be  considered Appropriate interfaces, communication protocols and related  collaborative information must be specified Browser configuration issues must be identified Testing requirements should be defined

Client­side
 

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

46

Relationship­Navigation Analysis
 

Relationship­navigation analysis (RNA) identifies relationships  among the elements uncovered as part of the creation of the analysis  model Steps:
    

Stakeholder analysis—identifies the various user categories and  establishes an appropriate stakeholder hierarchy Element analysis—identifies the content objects and functional elements  that are of interest to end users Relationship analysis—describes the relationships that exist among the  WebApp elements Navigation analysis—examines how users might access individual  elements or groups of elements Evaluation analysis—considers pragmatic issues (e.g., cost/benefit)  associated with implementing the relationships defined earlier

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

47

Navigation Analysis­I
      

Should certain elements be easier to reach (require fewer navigation  steps) than others? What is the priority for presentation? Should certain elements be emphasized to force users to navigate in  their direction? How should navigation errors be handled? Should navigation to related groups of elements be given priority  over navigation to a specific element.  Should navigation be accomplished via links, via search­based  access, or by some other means? Should certain elements be presented to users based on the context  of previous navigation actions? Should a navigation log be maintained for users?
48

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

Navigation Analysis­II

 

Should a full navigation map or menu (as opposed to a single “back”  link or directed pointer) be available at every point in a user’s  interaction? Should navigation design be driven by the most commonly expected  user behaviors or by the perceived importance of the defined  WebApp elements? Can a user “store” his previous navigation through the WebApp to  expedite future usage? For which user category should optimal navigation be designed? How should links external to the WebApp be handled? overlaying  the existing browser window? as a new browser window? as a  separate frame?
49

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

Software Engineering: A Practitioner’s Approach,  6/e

Chapter 19 Design Modeling for WebApps
copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

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

50

Design & WebApps
“There are essentially two basic approaches to design: the  artistic ideal of expressing yourself and the engineering  ideal of solving a problem for a customer.”  Jakob Nielsen

When should we emphasize WebApp design?
 

when content and function are complex when the size of the WebApp encompasses hundreds of content  objects, functions, and analysis classes when the success of the WebApp will have a direct impact on  the success of the business 
51

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

Design & WebApp Quality

Security
  

Rebuff external attacks Exclude unauthorized access Ensure the privacy of users/customers the measure of the percentage of time that a WebApp is  available for use Can the WebApp and the systems with which it is interfaced  handle significant variation in user or transaction volume

Availability

Scalability

Time to Market
52

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

Quality Dimensions for End­Users

Time
 

Structural
   

How much has a Web site changed since the last upgrade?  How do you highlight the parts that have changed?  How well do all of the parts of the Web site hold together.  Are all links inside and outside the Web site working?  Do all of the images work?  Are there parts of the Web site that are not connected?  Does the content of critical pages match what is supposed to be there? Do key phrases exist continually in highly­changeable pages?  Do critical pages maintain quality content from version to version?  What about dynamically generated HTML pages? 
53

Content
   

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

Quality Dimensions for End­Users

Accuracy and Consistency
 

Response Time and Latency 
  

Are today's copies of the pages downloaded the same as yesterday's? Close  enough?  Is the data presented accurate enough? How do you know?  Does the Web site server respond to a browser request within certain  parameters?  In an E­commerce context, how is the end to end response time after a  SUBMIT?  Are there parts of a site that are so slow the user declines to continue working  on it?  Is the Browser­Web­Web site­Web­Browser connection quick enough?  How does the performance vary by time of day, by load and usage?  Is performance adequate for E­commerce applications? 

Performance
  

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

54

WebApp Design Goals

Consistency
 

Content should be constructed consistently Graphic design (aesthetics) should present a consistent look across all parts of the WebApp Architectural design should establish templates that lead to a consistent hypermedia structure Interface design should define consistent modes of interaction, navigation and content display Navigation mechanisms should be used consistently across all WebApp elements

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

55

WebApp Design Goals
   

Identity
 

Establish an “identity” that is appropriate for the business purpose The user expects robust content and functions that are relevant to the user’s needs designed in a manner that is intuitive and predictable the look and feel of content, interface layout, color coordination, the balance of  text, graphics and other media, navigation mechanisms must appeal to end­ users With all appropriate environments and configurations

Robustness Navigability

Visual appeal

Compatibility

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

56

WebE Design Pyramid
user Interface design Aesthetic design Content design Navigation design Architecture design Component design technology

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

57

WebApp Interface Design

Where am I?  The interface should 
 

What can I do now? The interface should always help the user  understand his current options
  

 provide an indication of the WebApp that has been accessed   inform the user of her location in the content hierarchy. what functions are available? what links are live? what content is relevant?

Where have I been, where am I going?  The interface must facilitate  navigation. 

Provide a “map” (implemented in a way that is easy to understand) of  where the user has been and what paths may be taken to move  elsewhere within the WebApp.
58

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

Effective WebApp Interfaces

Bruce Tognozzi [TOG01] suggests…

Effective interfaces are visually apparent and forgiving,  instilling in their users a sense of control. Users quickly see the  breadth of their options, grasp how to achieve their goals, and  do their work. Effective interfaces do not concern the user with the inner  workings of the system. Work is carefully and continuously  saved, with full option for the user to undo any activity at any  time. Effective applications and services perform a maximum of work,  while requiring a minimum of information from users.
59

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

Interface Design Principles­I
   

Anticipation—A WebApp should be designed so that it anticipates the  use’s next move.  Communication—The interface should communicate the status of any  activity initiated by the user Consistency—The use of navigation controls, menus, icons, and  aesthetics (e.g., color, shape, layout) Controlled autonomy—The interface should facilitate user movement  throughout the WebApp, but it should do so in a manner that enforces  navigation conventions that have been established for the application. Efficiency—The design of the WebApp and its interface should  optimize the user’s work efficiency, not the efficiency of the Web  engineer who designs and builds it or the client­server environment that  executes it. executes it

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

60

Interface Design Principles­II
 

Focus—The WebApp interface (and the content it presents) should  stay focused on the user task(s) at hand.  Fitt’s Law—“The time to acquire a target is a function of the distance  to and size of the target.” Human interface objects—A vast library of reusable human interface  objects has been developed for WebApps. Latency reduction—The WebApp should use multi­tasking in a way  that lets the user proceed with work as if the operation has been  completed.  Learnability— A WebApp interface should be designed to minimize  learning time, and once learned, to minimize relearning required  when the WebApp is revisited. 
61

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

Interface Design Principles­III

Maintain work product integrity—A work product (e.g., a form  completed by the user, a user specified list) must be automatically  saved so that it will not be lost if an error occurs. Readability—All information presented through the interface  should be readable by young and old. Track state—When appropriate, the state of the user interaction  should be tracked and stored so that a user can logoff and return  later to pick up where she left off. Visible navigation—A well­designed WebApp interface provides  “the illusion that users are in the same place, with the work brought  to them.”

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

62

Interface Design Workflow­I

    

Review information contained in the analysis model and refine as required. Develop a rough sketch of the WebApp interface layout. Map user objectives into specific interface actions. Define a set of user tasks that are associated with each action. Storyboard screen images for each interface action. Refine interface layout and storyboards using input from  aesthetic design.

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

63

Mapping User Objectives
Menu bar major functions

List of user objectives objective # 1 objective # 2 objective # 3 objective # 4 objective # 5 graphic objective # n Home page text copy
Navigation menu

graphic, logo, and company name

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

64

Interface Design Workflow­II

  

Identify user interface objects that are required to  implement the interface. Develop a procedural representation of the user’s  interaction with the interface. Develop a behavioral representation of the interface. Describe the interface layout for each state. Refine and review the interface design model.

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

65

Aesthetic Design
   

 

Don’t be afraid of white space. Emphasize content. Organize layout elements from top­left to bottom right.  Group navigation, content, and function geographically  within the page. Don’t extend your real estate with the scrolling bar. Consider resolution and browser window size when  designing layout.

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

66

Content Design

Develops a design representation for content objects

For WebApps, a content object is more closely aligned with a data object for conventional software

Represents the mechanisms required to instantiate their  relationships to one another.

analogous to the relationship between analysis classes and design components described in Chapter 11

A content object has attributes that include content-specific information and implementation-specific attributes that are specified as part of design
67

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

Design of Content Objects
PoutCmoet r dc o pnn pr u br atNme pr a e atNm pr ye atT p ds r tio ecip n pic re cete e Ite r a Nw m() d p y ecip n() is laDs r tio d p y T c Se is la ehpc 1 is pa of rt 1

Com pDescription

Sno es r

Cmr a ea

Cn o ae otr lPnl

SftFa r o etue 1

1 M rketingDescription a
text color font style font size line spacing text im size age background color

1..* Photogra ph
horizontal dim ension vertical dim ension border style

0..1 Schem tic a
horizontal dim ension vertical dim ension border style

0..1 Video
horizontal dim ension vertical dim ension border style audio volum e

1 TechDescription
text color font style font size line spacing text im size age background color

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

68

Architecture Design

Content architecture focuses on the manner in which content objects  (or composite objects such as Web pages) are structured for  presentation and navigation.

The term information architecture is also used to connote structures  that lead to better organization, labeling, navigation, and searching of  content objects.

WebApp architecture addresses the manner in which the application  is structured to manage user interaction, handle internal processing  tasks, effect navigation, and present content.  Architecture design is conducted in parallel with interface design,  aesthetic design and content design.

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

69

Content Architecture
Linear structure Grid structure

Network structure

Hierarchical structure

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

70

MVC Architecture

The model contains all application specific content and processing  logic, including 
  

all content objects access to external data/information sources, all processing functionality that are application specific the presentation of content and processing logic  access to external data/information sources, all processing functionality required by the end­user.

 The view contains all interface specific functions and enables 
  

The controller manages access to the model and the view and  coordinates the flow of data between them.
71

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

MVC Architecture
controller
user request or da ta brow ser m na user requests a ges selects m odel beha vior selects view response view selection beha vior request (sta cha te nge)

m odel
client HTM da L ta

enca psula functiona tes lity enca psula content objects tes incorpora a w tes ll ebApp sta tes da fromm ta odel

view
prepa da fromm res ta odel request upda fromm tes odel presents view selected by controller

upda request te

externa da l ta

server

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

72

Navigation Design

Begins with a consideration of the user hierarchy and  related use­cases 

Each actor may use the WebApp somewhat differently and  therefore have different navigation requirements

As each user interacts with the WebApp, she encounters  a series of navigation semantic units (NSUs)

NSU—“a set of information and related navigation structures  that collaborate in the fulfillment of a subset of related user  requirements”

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

73

Navigation Semantic Units

Navigation semantic unit

Ways of navigation (WoN)—represents the best navigation way  Ways of navigation (WoN)— or path for users with certain profiles to achieve their desired  goal or sub­goal. Composed of …

Navigation nodes (NN) connected by Navigation links link12 NN1 link13 NN3 link24 NN4 link34 NSU

NN2

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

74

Creating an NSU
< navigation link> < > request alternative < navigation link> < > recommend component(s) ProductComponent Room < navigation link> < > show ProductComponent < navigation link> < > select Room

< navigation link> < > return to Room < navigation link> < > view BillOfMaterials BillOfMaterials

< navigation link> < > show description < navigation link> < > purchase ProductComponent CompDescription

< navigation link> < > purchase ProductComponent

M rke g e tio a tin D scrip n te D scrip n ch e tio sch mtic ea po g p h to ra h vid o e

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

75

Navigation Syntax
 

Individual navigation link—text­based links, icons, buttons and  switches, and graphical metaphors.. Horizontal navigation bar—lists major content or functional  categories in a bar containing appropriate links. In general, between  4 and 7 categories are listed.  Vertical navigation column
 

lists major content or functional categories lists virtually all major content objects within the WebApp.

Tabs—a metaphor that is nothing more than a variation of the  navigation bar or column, representing content or functional  categories as tab sheets that are selected when a link is required. Site maps—provide an all­inclusive tab of contents for navigation to  all content objects and functionality contained within the WebApp.
76

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

Component­Level Design

WebApp components implement the following  functionality
 

 

perform localized processing to generate content and navigation  capability in a dynamic fashion  provide computation or data processing capability that are  appropriate for the WebApp’s business domain  provide sophisticated database query and access  establish data interfaces with external corporate systems.

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

77

Hypermedia Design Patterns­I

Architectural patterns.
 

assist in the design of content and WebApp architecture many architectural patterns are available (e.g., Java Blueprints at  java.sun.com/blueprints/) recommend methods for combining WebApp components (e.g., content objects, functions) into composite components. assist in the design of NSUs, navigation links and the overall  navigation flow of the WebApp. _
78

Component construction patterns.

Navigation patterns. 

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

Hypermedia Design Patterns­II

Presentation patterns
 

how to organize user interface control functions for better usability how to show the relationship between a interface action and the content objects it affects how to establish effective content hierarchies, and many others. how the interface informs the user of the consequences of a specific action how a user expands content based on usage context and user desires how to best describe the destination that is implied by a link how to inform the user about the status of an on-going interaction, and others.
79

Behavior/user interaction patterns
   

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

Patterns Repositories

Hypermedia Design Patterns Repository

http://www.designpattern.lu.unisi.ch/ http://www.pliant.org/personal/Tom_Erickson/InteractionPatterns.html http://www.welie.com/patterns/ http://www8.org/w8-papers/5b-hypertext-media/improving/improving.html http://www.anamorph.com/docs/patterns/default.html http://www.mit.edu/~jtidwell/interaction_patterns.html http://www.rdrop.com/~half/Creations/Writings/Web.patterns/index.html http://www.cs.brown.edu/~rms/InformationStructures/Indexing/Overview.html

InteractionPatterns by TomErickson

Web Design Patterns by Martijn vanWelie

Improving Web Information Systems with Navigational Patterns

An HTML 2.0 Pattern Language

Common Ground - A Pattern Language for HCI Design

Patterns for Personal Web Sites

Indexing Pattern Language

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

80

OOHDM

Object-Oriented Hypermedia Design Method (OOHDM)
abst ract int erface design Abstract interface objects, responses to external events, transformations Mapping between navigation and perceptible objects

concept ual design Classes, sub-systems, relationships, attributes

navigat ional design Nodes, links, access structures, navigational contexts, navigational transformations Mapping between conceptual and navigation objects

implement at ion

w ork products

executable WebApp

Classification, composition, design m echanism aggregation, s generalization specialization

Resource provided by target environment

design concerns

Modeling semantics of the application domain

Takes into account user profile and task. Emphasis on cognitive aspects.

Modeling perceptible objects, implementing chosen metaphors. Describe interface for navigational objects

Correctness; Application performance; completeness

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

81

Conceptual Schema
custom selects com er ponent PoutCmoet r dc o pnn pr u br atNme pr a e atNm pr ye atT p ds r tio ecip n pic re cete e Ite () r a Nw m gtDs r tio e ecip n() gtT c Se e ehpc com ponent recom enda m tion requested B fMteia illO a r ls idn r etifie BMis oL t nmeIte s u br m pic T ta r eo l adn y() dEtr dle Etr () e ten y eitEtr d n y() nm() ae c mu Pic o pter e() SftFa r o etue BM m o Ite custom ercontinues com ponent selection qatity un pr u br atNme pr a e atNm pr ye atT p pic re ad L t () dtois dle fr mis () e te o L t gtNx is n y () e etL tEtr

Ro om r o Nm oma e d es n imnios eteioWdw x r r ino s eteioDos x r r or Sno es r

Cmr a ea

Cn o ae otr lPnl

Odr re odr u br r eNme c s mr fo uto eIn b fMteia illO a r ls s ipinIn h p g fo b g fo illinIn

custom er requests purcha se

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

82

Design Metrics
    

Does the user interface promote usability? Are the aesthetics of the WebApp appropriate for the application  domain and pleasing to the user? Is the content designed in a manner that imparts the most  information with the least effort? Is navigation efficient and straightforward? Has the WebApp architecture been designed to accommodate the  special goals and objectives of WebApp users, the structure of  content and functionality, and the flow of navigation required to  use the system effectively? Are components designed in a manner that reduces procedural  complexity and enhances the correctness, reliability and  performance?
83

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

Software Engineering: A Practitioner’s Approach,  6/e

Chapter 20 Testing Web Applications
copyright © 1996, 2001, 2005

R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and  are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005

84

Testing Quality Dimensions-I

Content is evaluated at both a syntactic and semantic level.

Function is tested for correctness, instability, and general  conformance to appropriate implementation standards (e.g.,Java or  XML language standards).  Structure is assessed to ensure that it 
  

syntactic level—spelling, punctuation and grammar are assessed for  text­based documents.  semantic level—correctness (of information presented), consistency  (across the entire content object and related objects) and lack of  ambiguity are all assessed.

properly delivers WebApp content and function  is extensible  can be supported as new content or functionality is added. 

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

85

Testing Quality Dimensions-II

Usability is tested to ensure that each category of user 
 

is supported by the interface can learn and apply all required navigation syntax and semantics all navigation syntax and semantics are exercised to uncover any  navigation errors (e.g., dead links, improper links, erroneous links).

Navigability is tested to ensure that

Performance is tested under a variety of operating conditions,  configurations, and loading to ensure that 
 

the system is responsive to user interaction the system handles extreme loading without unacceptable operational  degradation

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

86

Testing Quality Dimensions-III

Compatibility is tested by executing the WebApp in a  variety of different host configurations on both the client  and server sides. 

The intent is to find errors that are specific to a unique host  configuration.

Interoperability is tested to ensure that the WebApp  properly interfaces with other applications and/or  databases. Security is tested by assessing potential vulnerabilities and  attempting to exploit each. 

Any successful penetration attempt is deemed a security failure.

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

87

WebApp Testing Strategy-I
    

The content model for the WebApp is reviewed to  uncover errors.  The interface model is reviewed to ensure that all use­ cases can be accommodated.  The design model for the WebApp is reviewed to  uncover navigation errors.  The user interface is tested to uncover errors in  presentation and/or navigation mechanics. Selected functional components are unit tested. 

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

88

WebApp Testing Strategy-II
 

 

Navigation throughout the architecture is tested.  The WebApp is implemented in a variety of different environmental  configurations and is tested for compatibility with each  configuration.  Security tests are conducted in an attempt to exploit vulnerabilities  in the WebApp or within its environment. Performance tests are conducted. The WebApp is tested by a controlled and monitored population of  end­users

 the results of their interaction with the system are evaluated for content  and navigation errors, usability concerns, compatibility concerns, and  WebApp reliability and performance.
89

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

The Testing Process
C te t on n Te g stin In rfa te ce Te g stin ur se In rfa e te c d sig e n A sth tic d sig e e e n C te t d sig on n e n Nv a d sig a ig tion e n A h c red sig rc ite tu e n C p e t d sig omon n e n te h olog cn y Nv a a ig tion Te g stin

C p et om on n Te g stin C fig ra on u tion Te g stin P rform n e a ce Te g stin S cu e rity Te g stin

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

90

Content Testing

Content testing has three important objectives: 

 to uncover syntactic errors (e.g., typos, grammar mistakes) in  text­based documents, graphical representations, and other  media  to uncover semantic errors (i.e., errors in the accuracy or  completeness of information) in any content object presented as  navigation occurs, and   to find errors in the organization or structure of content that is  presented to the end­user.

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

91

Assessing Content Semantics
         

Is the information factually accurate? Is the information concise and to the point? Is the layout of the content object easy for the user to understand? Can information embedded within a content object be found easily? Have proper references been provided for all information derived from other  sources? Is the information presented consistent internally and consistent with  information presented in other content objects? Is the content offensive, misleading, or does it open the door to litigation? Does the content infringe on existing copyrights or trademarks? Does the content contain internal links that supplement existing content? Are  the links correct? Does the aesthetic style of the content conflict with the aesthetic style of the  interface?
92

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

Database Testing
clien layer - u in t ser terface
H M scrip TL ts

server layer - W Ap eb p

Tests are defined for each layer

u r d ta se a

server layer - d tran ata sform ation
u r d ta se a SL Q

server layer - d m ag en ata an em t
ra d ta wa SL Q

d ase layer - d access atab ata

d ase atab

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

93

User Interface Testing
 

Interface features are tested to ensure that design rules, aesthetics,  and related visual content is available for the user without error. Individual interface mechanisms are tested in a manner that is  analogous to unit testing. Each interface mechanism is tested within the context of a use­case  or NSU (Chapter 19) for a specific user category. The complete interface is tested against selected use­cases and NSUs  to uncover errors in the semantics of the interface. The interface is tested within a variety of environments (e.g.,  browsers) to ensure that it will be compatible.  browsers) to ensure that it will be compatible.

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

94

Testing Interface Mechanisms-I
 

 

Links—navigation mechanisms that link the user to some other  content object or function. Forms—a structured document containing blank fields that are filled  in by the user. The data contained in the fields are used as input to  one or more WebApp functions. Client­side scripting—a list of programmed commands in a scripting  language (e.g., Javascript) that handle information input via forms  or other user interactions Dynamic HTML—leads to content objects that are manipulated on  the client side using scripting or cascading style sheets (CSS). Client­side pop­up windows—small windows that pop­up without  user interaction. These windows can be content­oriented and may  require some form of user interaction.
95

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

Testing Interface Mechanisms-II

CGI scripts—a common gateway interface (CGI) script implements a  standard method that allows a Web server to interact dynamically with  users (e.g., a WebApp that contains forms may use a CGI script to process  the data contained in the form once it is submitted by the user). Streaming content—rather than waiting for a request from the client­side,  content objects are downloaded automatically from the server side. This  approach is sometimes called “push” technology because the server pushes  data to the client. Cookies—a block of data sent by the server and stored by a browser as a  consequence of a specific user interaction. The content of the data is  WebApp­specific (e.g., user identification data or a list of items that have  been selected for purchase by the user). Application specific interface mechanisms—include one or more “macro”  interface mechanisms such as a shopping cart, credit card processing, or a  shipping cost calculator.
96

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

Usability Tests
 

Design by WebE team … executed by end­users Testing sequence …
    

Define a set of usability testing categories and identify goals for each. Design tests that will enable each goal to be evaluated. Select participants who will conduct the tests. Instrument participants’ interaction with the WebApp while testing is  conducted. Develop a mechanism for assessing the usability of the WebApp  the usability of a specific interface mechanism (e.g., a form) can be assessed the usability of a complete Web page (encompassing interface mechanisms,  data objects and related functions) can be evaluated the usability of the complete WebApp can be considered. 

different levels of abstraction: 
 

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

97

Compatibility Testing
 

Compatibility testing is to define a set of “commonly encountered” client side computing configurations and their variants Create a tree structure identifying 
     

Derive a series of compatibility validation tests
 

each computing platform typical display devices the operating systems supported on the platform the browsers available likely Internet connection speeds similar information. 

derived from existing interface tests, navigation tests, performance tests, and  security tests.  intent of these tests is to uncover errors or execution problems that can be  traced to configuration differences.  

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

98

Component-Level Testing
 

Focuses on a set of tests that attempt to uncover errors in  WebApp functions Conventional black­box and white­box test case design  methods can be used Database testing is often an integral part of the  component­testing regime

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

99

Navigation Testing

The following navigation mechanisms should be tested:
  

  

Navigation links—these mechanisms include internal links within the WebApp,  external links to other WebApps, and anchors within a specific Web page.  Redirects—these links come into play when a user requests a non­existent URL or  selects a link whose destination has been removed or whose name has changed.  Bookmarks—although bookmarks are a browser function, the WebApp should be  tested to ensure that a meaningful page title can be extracted as the bookmark is  created. Frames and framesets—tested for correct content, proper layout and sizing,  download performance, and browser compatibility Site maps—Each site map entry should be tested to ensure that the link takes the  user to the proper content or functionality. Internal search engines—Search engine testing validates the accuracy and  completeness of the search, the error­handling properties of the search engine,  and advanced search features

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

100

Testing Navigation Semantics-I
  

Is the NSU achieved in its entirety without error? Is every navigation node (defined for a NSU) reachable within the context  of the navigation paths defined for the NSU? If the NSU can be achieved using more than one navigation path, has every  relevant path been tested? If guidance is provided by the user interface to assist in navigation, are  directions correct and understandable as navigation proceeds? Is there a mechanism (other than the browser ‘back’ arrow) for returning to  the preceding navigation node and to the beginning of the navigation path. Do mechanisms for navigation within a large navigation node (i.e., a long  web page) work properly? If a function is to be executed at a node and the user chooses not to provide  input, can the remainder of the NSU be completed?
101

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

Testing Navigation Semantics-II
 

If a function is executed at a node and an error in function  processing occurs, can the NSU be completed? Is there a way to discontinue the navigation before all nodes have  been reached, but then return to where the navigation was  discontinued and proceed from there? Is every node reachable from the site map? Are node names  meaningful to end­users? If a node within an NSU is reached from some external source, is it  possible to process to the next node on the navigation path. Is it  possible to return to the previous node on the navigation path? Does the user understand his location within the content  architecture as the NSU is executed?
102

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

Configuration Testing

Server­side
       

Is the WebApp fully compatible with the server OS? Are system files, directories, and related system data created correctly when the  WebApp is operational? Do system security measures (e.g., firewalls or encryption) allow the WebApp to  execute and service users without interference or performance degradation? Has the WebApp been tested with the distributed server configuration (if one  exists) that has been chosen? Is the WebApp properly integrated with database software? Is the WebApp  sensitive to different versions of database software? Do server­side WebApp scripts execute properly? Have system administrator errors been examined for their affect on WebApp  operations? If proxy servers are used, have differences in their configuration been addressed  with on­site testing?
103

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

Configuration Testing

Client­side
     

Hardware—CPU, memory, storage and printing devices Operating systems—Linux, Macintosh OS, Microsoft Windows, a  mobile­based OS Browser software—Internet Explorer, Mozilla/Netscape, Opera,  Safari, and others  User interface components—Active X, Java applets and others Plug­ins—QuickTime, RealPlayer, and many others Connectivity—cable, DSL, regular modem, T1

The number of configuration variables must be reduced  to a manageable number
104

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

Security Testing

Designed to probe vulnerabilities of the client­side  environment, the network communications that occur as  data are passed from client to server and back again, and  the server­side environment On the client­side, vulnerabilities can often be traced to  pre­existing bugs in browsers, e­mail programs, or  communication software. On the server­side, vulnerabilities include denial­of­ service attacks and malicious scripts that can be passed  along to the client­side or used to disable server  operations
105

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

Performance Testing
      

Does the server response time degrade to a point where it is  noticeable and unacceptable? At what point (in terms of users, transactions or data loading) does  performance become unacceptable? What system components are responsible for performance  degradation? What is the average response time for users under a variety of  loading conditions? Does performance degradation have an impact on system security? Is WebApp reliability or accuracy affected as the load on the system  grows? What happens when loads that are greater than maximum server  capacity are applied?
106

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

Load Testing

The intent is to determine how the WebApp and its  server­side environment will respond to various loading  conditions
  

N, the number of concurrent users T, the number of on­line transactions per unit of time D, the data load processed by the server per transaction

Overall throughput, P, is computed in the following  manner:

P =  N x T x D

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

107

Stress Testing
     

 

Does the system degrade ‘gently’ or does the server shut down as capacity is  exceeded? Does server software generate “server not available” messages? More generally, are  users aware that they cannot reach the server? Does the server queue requests for resources and empty the queue once capacity  demands diminish?  Are transactions lost as capacity is exceeded?  Is data integrity affected as capacity is exceeded? What values of N, T, and D force the server environment to fail? How does failure  manifest itself? Are automated notifications sent to technical support staff at the  server site? If the system does fail, how long will it take to come back on­line? Are certain WebApp functions (e.g., compute intensive functionality, data streaming  capabilities) discontinued as capacity reaches the 80 or 90 percent level?

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

108

Sign up to vote on this title
UsefulNot useful