UCLA CS130 Software Engineering

Web Engineering
Winter, 2002
Lecture Notes
February 4, 2002

Announcements

Summary of Last Lecture

Todays Lecture

1. Web Engineering
1.1. Attributes of Web-Based systems
1.2. The Web Engineering Process
1.3. A Web Engineering Framework
1.4. Formulating and Analyzing Web-Based Systems
1.5. Designing Web-based Applications
1.6. Testing Web-based Applications
1.7. Management Issues
2. Attributes of Web-Based systems web-based systems significantly different from other
categories of SW. Majority of web apps exhibit following attributes:
2.1. Network intensive by definition. Resides on a network; can serve wide variety of
clients.
2.2. Content driven many web apps present text/graphics/audio content as primary
function. Somewhat different than classical Input->Transformation->Output idea
of SW.
2.3. Continuous Evolution web applications evolve nearly continuously, not as a nice
series of planned incremental releases. For many sites, content may be updated at
very short intervals. E-commerce sites are good examples sites may run specials,
announce new inventory, price reductions, etc. News media sites (CNN, BBC, Fi-
nancial Times) are also good examples their content changes with breaking stories
throughout the day.

Lowe likens this continuous evolution to gardening developers prepare the infra-
structure (garden layout), plant and tend the content that grows within the infrastruc-
ture. Developers also act as gardeners by pruning dead branches. Important point
here is that web application and development is different than the classical develop-
ment and maintenance weve seen so far.

2.4. Required characteristics driving development process

2.4.1. Immediacy development time for web application is much shorter than for
traditional SW system matter of days, weeks, or months. Traditional sys-
tems (e.g., MIS systems, air traffic control systems, banking systems) can

1
 take years to develop. Development steps must be adapted to compressed
timeframe.
2.4.2. Security for web application to be useful, sensitive data (e.g., credit card
numbers, credit ratings, personal identification information) and data trans-
missions (transactions between customers and server for an e-commerce
site) must be protected. The application and the environment in which it
runs should themselves be resistant to attacks to minimize downtime de-
pending on the type of application, an hour of downtime can cost a business
millions of dollars (ISSRE2000 keynote speech).
2.4.3. Aesthetics Large part of a web sites appeal is its look and feel. For e-
commerce, aesthetics can have as much to do with success as technical de-
sign.
2.5. Web Application Categories
2.5.1. Informational read-only content (e.g., CNN, Financial Times)
2.5.2. Download download information from a server (e.g., GNU download
sites).
2.5.3. Customizable user customizes site to specific needs (e.g., My Netscape)
2.5.4. Interaction users communicate among themselves chat rooms, instant
messaging, bulletin boards.
2.5.5. User input forms-based input advanced search engines, for instance
2.5.6. Transaction oriented users make a request thats fulfilled by the applica-
tion (e.g., placing an order from Amazon.com).
2.5.7. Service oriented application provides a service (e.g., helps calculate loan
payments, estimated tax payments).
2.5.8. Portal provides links to other Web content or services outside of the appli-
cations domain.
2.5.9. Database access query and extract information from a database. This is
characteristic of many web-based problem reporting and tracking systems.
2.5.10. Data warehousing query a large collection of databases and extract infor-
mation.
2.6. Quality Attributes most important ones are:
2.6.1. Usability is the system easy to learn? Easy to re-learn? Are the controls
placed in obvious places? Is functionality obvious from the controls? Are
controls needed to do a particular thing grouped in one place?
2.6.2. Functionality
2.6.3. Reliability
2.6.4. Efficiency
2.6.5. Maintainability

Olsinas quality requirements tree provides a good overview (figure below).

2
 Global site understandability
On-line feedback, help features
Interface/aesthetic features
Special features
Usability
Searching and retrieving
Navigation and browsing
Functionality Application domain-related features

Correct link processing

Reliability Error recovery
User input validation and recovery

Efficiency Response time performance

Page generation speed
Graphics generation speed
Maintainability Ease of correction
Adaptability
Extensibility

2.7. Relevant Technologies component based development, security, and internet stan-
dards are enabling technologies. All 3 required to build high-quality web applica-
tions.
2.7.1. Component-based development three major infrastructure standards avail-
able:
2.7.1.1. CORBA
2.7.1.2. COM/DCOM
2.7.1.3. Java Beans

Infrastructure standards include prebuilt components, tools, and techniques.

Enable deployment of third-party and custom components, allow compo-
nents to communicate with one another and system-level services
2.7.2. Security unauthorized access needs to be prevented. Various types of un-
authorized access theft or destruction of data, defacing/disabling web ap-
plication. Types of security measures include
2.7.2.1. Encryption for data transmission, protection of sensitive data
2.7.2.2. Firewalls
2.7.3. Internet standards
2.7.3.1. HTML dominant standard over past 10 years for creating web
application content and structure. Allows developers to use a se-
ries of tags to describe appearance of text, graphics, audio/video,
etc.
2.7.3.2. XML more flexible than HTML can cope with more complex
applications. Developers can define custom tags whose meaning is
defined in information transmitted to client site.
3. The Web Engineering Process
3.1. Can we apply SW engineering to building web applications? Yes, but processes and
methods need to be adapted to short timeframe of web application development.

3
 3.1.1. Immediacy and continuous evolutionary nature of web application suggest
an evolutionary development process (e.g., spiral)
3.1.2. Network-intensive nature of application means a wide variety of people will
be able to use it. Requirements gathering is especially important here
need to make sure all types of users are represented in requirements gather-
ing process.
3.1.3. Content-driven nature, emphasis on aesthetics suggest activities in parallel
to classical development: for instance, copywriting for text content, graphic
design and layout, musical composition/performance, video produc-
tion/editing, animation..
4. A Web Engineering Framework
4.1. Evolution of web applications from relatively simple static information sources to
complex dynamic applications increases need to apply solid SW management and
engineering principles.
4.2. One framework for web engineering shown below encompasses a process model
populated with framework activities, engineering tasks.

Architectural
Planning Design
Content
Analysis
Design
Formulation
Navigation
Design
Engineering
Customer Production
evaluation Interface
Design
Page generation
and testing

Looks a lot like spiral model accommodates immediacy and continuous evolution-
ary nature.

Six task regions are:

4.2.1. Formulation identify goals and objectives of web application establish
scope.
4.2.2. Planning Estimate project cost effort, identify and evaluate risks, develop
schedules (detailed one for initial increment of application, coarser ones for
later increments of application)
4.2.3. Analysis identify technical requirements and content that will be incorpo-
rated
4.2.4. Engineering - two concurrent activity paths during engineering somewhat
classical design, and content design/production. Goal of content de-
sign/production is to design, produce, acquire all content of different types

4
 that will be incorporated into the application. Content design and produc-
tion can include writing copy, creating and laying out graphics, composing
and recording music.
4.2.5. Page generation and testing implementation phase extensive use of
automated tools to generate pages. Content defined during engineering is
merged with architectural, navigational, and interface designs to make ex-
ecutable web pages. Testing exercise navigation; discover errors in ap-
plets, scripts, forms; ensure application will operate properly in required en-
vironments (e.g., Internet Explorer 5.0, Netscape 4.7 and higher).
4.2.6. Customer evaluation change requests made by customer at this point; ap-
proved changes are merged into next version.
5. Formulating and Analyzing Web-Based Systems
5.1. Starts with defining goals of web application; ends with development of analysis
model or requirements specification
5.2. Formulation work with customer to establish goals and objectives (same as cassi-
cal software development). Also, problem is scoped and bounded looks a lot like
scoping and bounding the problem in classical software planning.
5.3. Analysis - identifies data, functional, behavioral requirements for web app just like
classical analysis.
5.4. Formulation
5.4.1. Following questions should be answered at beginning of formulation:
5.4.1.1. What is the motivation of the web app?
5.4.1.2. Why is the web app needed?
5.4.1.3. Who will use the web app?

State answers as succinctly as possible at this stage.

Example consider an airline reservation system:

Answer to question 1: MonopolyAir.com will allow travelers to find and

purchase any type of air travel reservation or travel package offered by Mo-
nopoly East-West Airlines.

Note no detail of how this product will be provided at this stage. Bound-
ing problem is the goal at this point.

Answer to question 2: MonopolyAir.com will allow us to sell directly to

travelers, eliminating ticket agent costs and travel agent commissions,
thereby improving the companys profitability. Our forecast shows that it
should also increase ticket sales 15% over current levels. Finally, it will
give us greater penetration into those areas that are not MonopolyAir hubs.

The last answer describes the demographics of the web application users:

5
 Answer to question 3: Projected users of MonopolyAir.com are frequent
MonopolyAir flyers, experienced flyers new to MonopolyAir, and new fly-
ers."

5.4.2. Use answers to questions specify goals for the web app
5.4.2.1. Information goals intent to provide specific content, information
to app users.
5.4.2.2. Applicative goals indicate ability to perform a particular task
within the app.

For our example, we might have the following goals:

Informational: MonopolyAir.com will provide travelers with informa-
tion on available air fares and travel packages.
Applicative: MonopolyAir.com will ask users if they are frequent Mo-
nopolyAir flyers, frequent flyers, or new flyers. Each type of user will
be offered promotions geared to level of travel experience.
5.4.3. Develop user profiles after developing goals. Describes following attributes
of users:
5.4.3.1. Background
5.4.3.2. Knowledge
5.4.3.3. Preferences
5.4.3.4.

For our example, user profile would identify characteristics of:

Frequent MonopolyAir flyers
Frequent flyers, but not on MonopolyAir
Novice/infrequent flyers
5.4.4. Develop statement of scope after goals, user profiles identified. In many
cases, goals are integrated into statement of scope.
5.4.5. Integration and Connectivity start thinking about how existing systems
will need to be integrated the web app. Often, databases are connected to a
web front end (as would be the case for our example existing reservation
and airfare databases would need to be integrated into the MonopolyAir web
app).
5.5. Analysis
5.5.1. Classical analysis concepts and principles (Chapter 11) applies without
modification to web applications.
5.5.2. Elaborate scope to create analysis model
5.5.3. Four types of analysis
5.5.3.1. Content analysis identify all content that will be provided by web
app. Includes text, graphics, audio, video. Data modeling tech-
niques described for structured analysis applicable to web applica-
tions.
5.5.3.2. Interaction analysis describes in detail how user will interact with
web app. Use cases can be used here; see the class handout or
Chapter 11.

6
 5.5.3.3. Functional analysis use cases developed for interaction analysis
define operations that will be applied to content this implies
processing functions which are described in detail during this
stage. Again, structured analysis methods can be used here.
5.5.3.4. Configuration analysis describes environment and infrastructure
in which application resides. For instance, the application can re-
side on an intranet, the Internet, or an Extranet (environment).
Also define infrastructure during this stage (e.g., degree to which a
database will be used to generate content for the app, use of an ex-
isting application to help user make loan calculations, etc.).
5.5.4. Detailed requirements specification recommended for large, complex apps.
However, theyre usually not seen. Why?
5.5.4.1. Continuous evolution can argue that this characteristic of web
app requirements makes documents obsolete before theyre done.
Even if this is true:
5.5.4.1.1. Need to have some type of analysis model that serves
as foundation for following design activity.
5.5.4.1.2. As a minimum, collect information from 4 analysis
activities and review it, modify as required, and or-
ganized into package that can be passed on to design-
ers.
6. Designing Web-based Applications
6.1. Dilemma immediacy and continuous evolution of web apps forces designer to:
6.1.1. Design applications that solve the immediate problem
6.1.2. Define an architecture that can evolve rapidly over time

Classically, these are mutually exclusive activities

6.2. Effective web-based design requires reuse of 4 technical elements
6.2.1. Design principles and methods design principles, methods for structured
analysis (previous lecture) also apply to web apps.
6.2.2. Design heuristics
6.2.3. Design patterns generic approach for solving some problem thats adapt-
able to wide variety of specific problems. For web apps, can apply these not
only to functional elements, but also documents, graphics, general aesthet-
ics.
6.2.4. Templates provides skeletal framework for any design pattern or docu-
ment in web app.
6.3. Architectural Design
6.3.1. Focuses on
6.3.1.1. Overall hypermedia structure
6.3.1.2. Application of design patterns/constructive templates to populate
the structure
Parallel activity is content design develops overall structure and layout of
information content that application will present
6.3.2. Structures 4 different types:

7
6.3.2.1. Linear used for a predictable, straight line sequence of actions
(e.g., tutorial, review of shopping basket and check-out). There
might be some optional flow or diversion, but main flow is straight
through.

Linear Linear with Linear with

optional flow diversions

6.3.2.2. Grid used when content can be organized in two or more dimen-
sions (e.g., TV manufacturer and size of TV). Only useful for
highly regular content. See below.

8
 6.3.2.3. Hierarchy most common type of organization. Example Ama-
zon.com has this type of structure. Select a broad category of
books, then travel along the set of branches in that category.

Note that its possible to cut across branches. Although it allows

rapid navigation, too much of it confuses users.
6.3.2.4. Fully-connected graph pure Web. Allows maximum naviga-
tional flexibility, but can also be very confusing to users. Typi-
cally used in navigating menus.
6.3.3. Architectural structures can be combined to form composite structures. For
instance, a web site might have an introductory tutorial (linear), followed by
a hierarchical structure leading to product descriptions, press releases, tech-
nical support, contact points, and a portal to related sites. Some supercom-
puter vendors and real-time Linux sites have this kind of mixed appearance.
6.3.4. Hypertext Design Patterns focus on design of navigation features making
it easier for user to move through the content.
6.3.4.1. Cycle returns user to a previously visited content node
6.3.4.2. Web ring grand cycle linking entire hypertexts in a tour of the
subject
6.3.4.3. Contour occurs when cycles impinge upon one another. Allows
navigation across paths defined by cycles.
6.3.4.4. Counterpoint adds hypertext commentary, interrupting content
narrative to provide additional information.
6.3.4.5. Mirrorworld presents content using different narrative threads,
each having a different point of view. When ordering a computer,
you can look at the specs from a technical or non-technical point of
view.

9
 6.3.4.6. Sieve guides users through a series of options to get to desired
content. Kelly Blue Book web site does this when asking if you
want to look at new or used cars, and then car type (e.g., luxury,
sports car, compact).
6.3.4.7. Neighborhood overlays a uniform navigational pattern across all
web pages. Gives users consistent navigation guidance regardless
of location within site.
6.4. Navigation Design
6.4.1. Done after architecture has been established and components (pages, ap-
plets, scripts) have been identified
6.4.2. Defines pathways letting users get to content and services. Accomplished
by
6.4.2.1. Identify semantics of navigation for different users whats the
best way for me to get where I want to be?. Different types of us-
ers may be guests, clients, administrators. Each role has different
levels of content access and different services available to it.
Navigation semantics for different user types will be different.
6.4.2.2. Define mechanics (syntax) of navigating
6.4.3. Semantics of Navigation for each goal associated with each user, create a
Semantic Navigation Unit.
6.4.3.1. SNU structure
6.4.3.1.1. Set of navigational substructures Ways of Navigat-
ing (WoN). WoN is best way for a particular user to
achieve a particular goal
6.4.3.1.2. WoN made of set of relevant Navigational Nodes
(NN e.g., web pages) connected by navigational
links. May include other SNUs.
6.4.3.1.3. SNUs may be aggregated to form higher-level SNUs,
or may be nested.
6.4.4. Mechanics of Navigation for each navigation link, determine the mecha-
nism (e.g., text-based link, icons, buttons, switches, )
6.4.4.1. Choose navigation links appropriate for content, consistent with
heuristics for high-quality interface design (e.g., icons should be
self-explanatory, icons should be differentiable from other icons,
descriptive text should be succinct)
6.4.4.2. Navigation Mechanism Conventions
6.4.4.2.1. Icons, graphical links should be clickable bevel
button edges, change edge color when clicked.
6.4.4.2.2. Provide audio/visual feedback to indicate a link has
been activated.
6.4.4.2.3. Text-based links use color and indicate links al-
ready traveled.
6.4.4.2.4.
6.4.4.3. Design navigation aids site maps, table of contents, search facil-
ity, indexes, dynamic help.
6.5. Interface Design

10
 6.5.1. User interface important in determining whether web app will be successful
well-designed interface improves users perception of site, but poorly-
designed one will tend to turn users away, regardless of how nice the con-
tent or services are. Need to attract users to site during their first visit.
Guidelines given below.
6.5.2. Web interface guidelines
6.5.2.1. Server errors turn users away even minor errors
6.5.2.2. Reading speed reading speed for a monitor is about 25% less
than that for reading hard copy. Dont give users too much text to
read, especially that explaining the operation of the web app or
how to navigate through it.
6.5.2.3. No under construction signs why disappoint users by calling
attention to something thats not there?
6.5.2.4. Dont make users scroll they prefer not to. Important informa-
tion should fit within the dimensions of a typical browser window.
6.5.2.5. Design navigation menus, headbars in a consistent fashion, and
should be available on all pages available to users. DONT RELY
ON BROWSER FUNCTIONS TO ASSIST IN NAVIGATION.
6.5.2.6. Functionality first dont let aesthetics get in the way. If you need
a button, use a simple button, not some nicely-rendered, but vague
icon or graphic.
6.5.2.7. Navigation options should be obvious. Dont make it necessary
for users to search to determine how to link to other content or ser-
vices.
6.5.3. User interface should always be structured, ergonomically sound. Doesnt
need to be flashy.
7. Testing Web-based Applications
7.1. Classical purpose of test exercise software in a systematic fashion to demonstrate
that it functions correctly and to find faults. Holds for web applications. Finding
faults is complicated by the fact that web apps reside on network and interoperate
with different operating systems, browsers, CPUs, communication protocols.
7.2. Summary of web testing approach
7.2.1. Review content model to discover errors similar to copy editing a
document. Look for factual errors, typographical errors, grammatical errors,
content inconsistencies, graphical representational errors, cross-referencing
errors. May use professional copy editor to do this for large web site.
7.2.2. Review design model to find navigation errors usage scenarios exer-
cised against architectural and navigational design. Help uncover naviga-
tion errors, such as the case in which users cannot reach a desired node.
Also, review navigation links to make sure they correspond with those
specified in each SNU for each user role.
7.2.3. Unit testing unit test selected processing components and web pages.
Classically, a unit is a stand-alone processing unit. For web apps, the small-
est testable unit in many cases is the web page, which encapsulates content,
links, and processing elements (e.g., forms, scripts, applets). Unit testing for

11
 web apps is driven by content, processing, and links, rather than focusing on
algorithmic detail as in classical unit test.
7.2.4. Construct architecture and conduct integration tests integration strat-
egy depends on architecture of app. For linear, grid, or simple hierarchical
structures, can use conventional integration approach. Can also use SNUs to
define sets of pages to integrate.
7.2.5. Test assembled web app - for overall functionality and content delivery.
Focuses on user-visible actions and user-recognizable output. Draw on use
cases to derive these tests. Use cases provide scenarios likely to uncover er-
rors in user interaction.
7.2.6. Compatibility testing - Implement web app in different environmental con-
figurations and test for compatibility define all probable operating sys-
tems, browsers, hardware configurations, and communications protocols in a
cross-reference matrix. Define configurations and test the application on
them to uncover errors.
7.2.7. User test get users representing all possible roles to exercise the system
under controlled and monitored conditions. Evaluate results for content and
navigation errors, usability problems, compatibility problems, and reliability
and performance.
7.3. Because web apps evolve continuously, testing is often a continuous activity. Tests
devised for earlier versions of an app are often used as regression tests for later ver-
sions.
8. Management Issues
8.1. Web app management complex
8.1.1. Many tasks done in parallel
8.1.2. Mixture of technical and non-technical tasks
8.2. Web Engineering Team
8.2.1. Organization can be done as described in Chapter 3 (DD, CD, CC).
8.2.2. Different players with different roles roles below
8.2.2.1. Content developer, provider
Marketing, sales staff provide product info, images
Media producers provide video, audio
Graphic designers provide layout, aesthetic content
Copywriters text-based content
Research staff find and format external content for place-
ment, reference
8.2.2.2. Web publisher
Organizes content for inclusion within web app
Liason between technical staff engineering web app and non-
technical staff providing content
Must understand content, web app technology
8.2.2.3. Web engineer technical staffer who gets involved in a wide vari-
ety of activities:
Requirements elicitation
Analysis modeling
Design

12
 Implementation
Testing
Needs good understanding of component technologies, cli-
ent/server architecture, HTML/XML, database technologies;
working knowledge of multi-media, network security, HW/SW
platforms, web-site support issues
8.2.2.4. Support specialist responsible for
Corrections
Adaptations
Enhancements includes updating content, implementing new
procedures and forms, navigation changes
8.2.2.5. Administrator (Web master) responsible for day-to-day opera-
tions of the web app
Develop, implement policies for operating web app
Establish support, feedback procedures
Implement security procedures, access rights
Measure, analyze web site traffic
Coordinate change control procedures
Coordinate with support specialists
Can also be involved in other technical activities (web engi-
neer, support specialist)
8.3. Project Management
8.3.1. Management techniques weve looked at apply (in theory) to web app de-
velopment. In practice, web app management is quite different
8.3.2. Complicating Factors
8.3.2.1. Development of web apps often outsourced. How do we know if
the vendor is good? What do we look for in a vendor? Whats a
reasonable cost? How much planning, scheduling, and risk man-
agement can we expect to be doing?
8.3.2.2. Web apps relatively new application area not much historical
data to use for estimation
8.3.2.3. Estimates predicated on a clear understanding of scope continu-
ous evolutionary nature of web app suggests scope will always be
changing. How can we deal with this and control costs and sched-
ule?
8.3.3. Management Guidelines
8.3.3.1. Initiating a project organizations need to perform some tasks be-
fore searching for a vendor to do the construction of the web app.
8.3.3.1.1. Many analysis activities should be performed inter-
nally identify users, internal stakeholders, overall
goals of app, information/services to be delivered,
competing web sites identified, and define quantita-
tive/qualitative measures of success. Document this
in a product specification.
8.3.3.1.2. Develop a rough design internally identify general
look and feel. Indicate type and volume of content to

13
 be presented, types of interactive processing (e.g,
forms, order entry) that will occur. Add this info to
product specification.
8.3.3.1.3. Develop rough project schedule, including milestones
for interim deliveries of the app as it evolves.
8.3.3.1.4. Specify degree of oversight, interaction with the ven-
dor name liaison to vendor, identify their responsi-
bilities and authority, define quality review points,
specify vendors responsibilities.
8.3.3.2. Vendor selection
8.3.3.2.1. Interview previous clients to determine vendors pro-
fessionalism, ability to meet schedule/budget, and
ability to communicate effectively
8.3.3.2.2. Identify chief engineer of successful past projects and
get them contractually obligated to your project
8.3.3.2.3. Examine samples of vendors work that are similar to
yours in look and feel and business area
8.3.3.3. Assessing price quote validity, estimate reliability estimation is
risky because of lack of historical data. Question isnt have we
gotten the best price? Rather:
8.3.3.3.1. Does the cost provide a direct or indirect return on in-
vestment that justifies the project?
8.3.3.3.2. Does the vendor providing the quote provide the pro-
fessionalism and experience we need?
8.3.3.4. The degree of project management you can expect or perform di-
rectly related to size and complexity of web app. For large, com-
plex projects, develop a detailed schedule for:
8.3.3.4.1. Work tasks
8.3.3.4.2. Software Quality Assurance checkpoints
8.3.3.4.3. Engineering work products
8.3.3.4.4. Customer review points (thats you dont forget to
include yourself in!)
8.3.3.4.5. Major milestones (e.g, delivery of version 1)

Vendor and contracting organization should jointly assess risks and

develop risk monitoring, mitigation, and management plan.

Define and document SQA, change control.

8.3.3.5. Assessing development schedule because web app development

tasks are on the order of weeks or a couple of months, the sched-
ules should be quite detailed. For instance, schedule work tasks
and minor milestones on a daily basis. Fine granularity is helpful
in recognizing schedule slippage before it threatens timely comple-
tion of the effort.
8.3.3.6. Managing scope

14
 8.3.3.6.1. Development process should be incremental can
freeze scope for one increment to create an opera-
tional version.
8.4. SCM Issues
8.4.1. As web apps become more important to business, more important to control
change to prevent:
8.4.1.1. Unauthorized posting of new product/service information
8.4.1.2. Erroneous functionality
8.4.1.3. Security holes that compromise organizations internal systems
8.4.2. Four issues in developing web app CM
8.4.2.1. Content to establish configuration control mechanisms, can apply
conventional data modeling and attach specialized properties to
each configuration object. Could use static or dynamic nature and
projected longevity as properties. Rigor of control mechanisms
would depend on properties of the object.
8.4.2.2. People need to make staff award of need for CM. Content de-
velopers may not recognize the need for CM, and will make
changes to content in an uncontrolled fashion. Define a CM pol-
icy, educate the staff, acquire tools and develop processes that will
help enforce it.
8.4.2.3. Scalability although a web app may start out small (and have
minimal change control), it can grow quite complex as it connects
with more databases, information systems, portals, data ware-
houses. Rigor of configuration control mechanisms should be ap-
propriate to scale of the application.
8.4.2.4. Politics who owns the web app controls it, but who owns it is of-
ten unclear. Following questions help determine who must adopt
CM policies for a web app:
8.4.2.4.1. Who is responsible for the accuracy of the informa-
tion presented by the app?
8.4.2.4.2. Who ensures that quality control procedures have
been followed?
8.4.2.4.3. Who is responsible for making changes (to content, to
functionality)?
8.4.2.4.4. Who pays for changes?
8.4.3. Open web SCM issues
8.4.3.1. How can we create a CM process that can accommodate the im-
mediacy, continuous evolution of a web app?
8.4.3.2. Introducing CM concepts, tools to those completely unfamiliar
with the technology (e.g., content developers)
8.4.3.3. Providing support for distributed development teams
8.4.3.4. Providing control in an environment where content changes on a
nearly continuous basis
8.4.3.5. Attaining granularity required to control large array of configura-
tion objects

15
8.4.3.6. Incorporating CM functionality into existing web development
tools
8.4.3.7. Managing changes to objects containing links to other objects

16