+ All Categories
Home > Documents > Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David...

Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David...

Date post: 31-May-2020
Category:
Upload: others
View: 5 times
Download: 0 times
Share this document with a friend
12
SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS, E-EDUCATION, AND E-SCIENCE 1 Characteristics of Web Development Processes David Lowe, Brian Henderson-Sellers Abstract- The nature of Web system develop- ment is significantly different from conventional software development. Amongst other factors, there is substantial uncertainty in both clients' un- derstanding of their needs and developers' under- standing of the system domain. We discuss these differences and the impact that they have on the development processes that are adopted for com- mercial Web systems. Index Terms- Software Engineering, Software re- quirements and specifications, Software develop- ment management I. INTRODUCTION W EB systems are often viewed as simply a form of software systems. Therefore, de- velopment approaches that have been established and refined for software systems development can readily be applied to the development of Web sys- tems. Whilst this is true to a limited extent, there is a growing recognition that Web systems have various unique characteristics that are only poorly addressed by conventional development practices. Development practices from related domains (soft- ware engineering, graphic design, marketing etc.) do not typically address these differences particu- larly well. Despite this there has been little consid- eration within the research literature of the impli- cations of these characteristics on the development process. This is in spite of the obvious growth in importance of these systems to business success. For example, a recent International Data Corp report predicted that U.S. expenditure on Web- based initiatives would grow from US$12billion in 1999 to US$43.6 billion in 2002. The systems be- ing developed leverage the infrastructure of the Internet and an increasingly complex set of Web standards, protocols and technologies to provide sophisticated business solutions that merge Web- based front-ends with complex back-end software. A/Prof David Lowe is with the Faculty of Engineering, Uni- versity of Technology, Sydney. E-mail: [email protected] Prof Brian Henderson-Sellers is with the Faculty of Infor- mation Technology, University of Technology, Sydney. E-mail: [email protected]. These solutions cover the spectrum from electronic commerce to information provision and manage- ment to business-to-business support systems. In this paper we consider the differences be- tween Web systems and conventional software sys- tems, and explore the implications of these dif- ferences for system modelling, development prac- tices and techniques, and overall development pro- cesses. We begin (in Section II) by discussing the differences between conventional software sys- tems and Web systems. In particular, we look at those aspects that are most likely to impact on the way in which we develop these systems. We then move on to look at the specific impacts on the approach to development. In Section III, we look at the need for different modelling approaches and, in Section IV, we consider the impacts on the broader process - particularly the tasks and ac- tivities that need to be carried out. Finally, in Section V, we speculate a little about the areas requiring most immediate attention and then con- clude the paper. II. DIFFERENCES BETWEEN WEB SYSTEMS AND CONVENTIONAL SYSTEMS There is a growing body of research that is attempting to understand the differences be- tween Web systems and conventional software sys- tems [1], [2], [3]. In general, a distinction is made between the unique characteristics of Internet- enabled systems that are technical (i.e. related to the specific technologies that are used and how these impact on the structure of the application) and those that are organisational (i.e. related to the ways in which organisations make use of these systems). A. Technical Differences There are obvious technical differences between Web systems and more conventional software and IT systems. The most significant of these are as follows:
Transcript
Page 1: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS, E-EDUCATION, AND E-SCIENCE 1

Characteristics of Web Development ProcessesDavid Lowe, Brian Henderson-Sellers

Abstract- The nature of Web system develop-ment is significantly different from conventionalsoftware development. Amongst other factors,there is substantial uncertainty in both clients' un-derstanding of their needs and developers' under-standing of the system domain. We discuss thesedifferences and the impact that they have on thedevelopment processes that are adopted for com-mercial Web systems.

Index Terms- Software Engineering, Software re-quirements and specifications, Software develop-ment management

I. INTRODUCTION

WEB systems are often viewed as simply aform of software systems. Therefore, de-

velopment approaches that have been establishedand refined for software systems development canreadily be applied to the development of Web sys-tems. Whilst this is true to a limited extent, thereis a growing recognition that Web systems havevarious unique characteristics that are only poorlyaddressed by conventional development practices.Development practices from related domains (soft-ware engineering, graphic design, marketing etc.)do not typically address these differences particu-larly well. Despite this there has been little consid-eration within the research literature of the impli-cations of these characteristics on the developmentprocess. This is in spite of the obvious growth inimportance of these systems to business success.For example, a recent International Data Corpreport predicted that U.S. expenditure on Web-based initiatives would grow from US$12billion in1999 to US$43.6 billion in 2002. The systems be-ing developed leverage the infrastructure of theInternet and an increasingly complex set of Webstandards, protocols and technologies to providesophisticated business solutions that merge Web-based front-ends with complex back-end software.

A/Prof David Lowe is with the Faculty of Engineering, Uni-versity of Technology, Sydney. E-mail: [email protected]

Prof Brian Henderson-Sellers is with the Faculty of Infor-mation Technology, University of Technology, Sydney. E-mail:[email protected].

These solutions cover the spectrum from electroniccommerce to information provision and manage-ment to business-to-business support systems.

In this paper we consider the differences be-tween Web systems and conventional software sys-tems, and explore the implications of these dif-ferences for system modelling, development prac-tices and techniques, and overall development pro-cesses. We begin (in Section II) by discussingthe differences between conventional software sys-tems and Web systems. In particular, we look atthose aspects that are most likely to impact onthe way in which we develop these systems. Wethen move on to look at the specific impacts onthe approach to development. In Section III, welook at the need for different modelling approachesand, in Section IV, we consider the impacts on thebroader process - particularly the tasks and ac-tivities that need to be carried out. Finally, inSection V, we speculate a little about the areasrequiring most immediate attention and then con-clude the paper.

II. DIFFERENCES BETWEEN WEB SYSTEMS

AND CONVENTIONAL SYSTEMS

There is a growing body of research thatis attempting to understand the differences be-tween Web systems and conventional software sys-tems [1], [2], [3]. In general, a distinction is madebetween the unique characteristics of Internet-enabled systems that are technical (i.e. relatedto the specific technologies that are used and howthese impact on the structure of the application)and those that are organisational (i.e. related tothe ways in which organisations make use of thesesystems).

A. Technical Differences

There are obvious technical differences betweenWeb systems and more conventional software andIT systems. The most significant of these are asfollows:

Page 2: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

2 SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS, E-EDUCATION, AND E-SCIENCE

Link between business model and architecturePossibly the most obvious difference between

web and traditional software development is seenin regard to the specific technologies that are usedand the ways in which these are interconnected.For example, the technical structure of Web sys-tems merges a sophisticated business architecture(that usually implies significant changes to thebusiness model of the client) with both a complexinformation architecture and a highly component-based technical architecture [1]. The linkage be-tween the business architecture and the technicaldesign of the system is much tighter than for con-ventional software systems. Similarly, the infor-mation architecture (which covers aspects such asthe content viewpoints, interface metaphors andnavigational structures) is substantially more so-phisticated than conventional software systems.

Open modularised architecturesRelated to the above point is the emphasis that

is typically placed on open and modularised ar-chitectures for web systems. Though not uniqueto Web systems, it is often more pronounced.Web systems are often constructed from multipleCOTS (commercial off-the-shelf) components thatare adapted and integrated together - particu-larly for the system back end middleware layers.This implies that strong integration skills becomemuch more critical in most Web projects.

Rapidly changing technologiesThe technology that underpins most web sys-

tems is changing very rapidly. This has severalconsequences. The first is that it increases theimportance of creating flexible solutions that canbe updated and migrated to new technologieswithminimal effort. For example, the need for reusabledata formats (such as XML) increases substan-tially. A second consequence is that developer'sunderstanding of these technologies is often re-stricted, thus increasing project risks.

Content is kingOf notable significant is the importance of con-

tent. Irrespective of the sophistication of the func-tionality and the creativity of the interface, a siteis likely to fail without appropriate, substantialand up-to-date content. This implies both an ef-fective information design as well as suitable con-tent management.

Increased emphasis on user interfaceWith conventional software systems, users must

make an (often considerable) investment in timeand effort to install and learn to use an applica-tion. With web applications, however, users canvery quickly switch from one web site to anotherwith minimal effort. As such, the need to engageusers and provide much more evident satisfactionof users' needs and achievement of their objec-tives becomes critical. The result is an increasedemphasis on the user interface and its associatedfunctionality.

A little more subtly, the emergence of author-ing tools have focused on supporting rapid devel-opment and on visual design rather than function-ality. This in turn has promoted a greater use ofdesigns as a part of a specification - and thus al-lows a more interactive process between gatheringrequirements and building solutions.

Increased importance of quality attributesWeb systems represent an increase in mission

critical applications that are often directly acces-sible to external users and customers. Flaws inapplications (be they usability, performance or ro-bustness) are therefore typically more visible ex-ternally and hence more problematic.

B. Organisational Differences

In addition to the technical differences, and pos-sibly more important than them, are a numberof organisational characteristics that are eitherunique or heightened in Web systems [1].

Client uncertaintyWith Internet-based systems, the technology,

development skills, business models and compet-ing systems are changing so rapidly that the do-main is often not only poorly understood, butalso constantly evolving [~i].This provides a sub-stantial degree of uncertainty in the project con-text, and consequently makes resolving require-ments very problematic. Indeed, clients often haveproblems not only articulating their needs, butalso in understanding whether a particular designwill satisfy their needs - as they have a poorunderstanding of their own needs with respect tothe Web. It is also worth noting that many webprojects are vision-driven rather than needs-drivenleading to an initial lack of clarity, consequently

Page 3: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

LOWE AND HENDERSON-SELLERS: CHARACTERISTICS OF WEB DEVELOPMENT PROCESSES

increasing the importance of incremental and pro-totyping approaches.

Changing business requirementsRelated to the previous point is the volatility in

requirements. Specifically, given that clients' un-derstanding of not only the technology's capabil-ities but also the potential impacts on their busi-nesses change dramatically during a project, it isnot surprising that the project scope and focuswill often evolve considerably during the courseof a project. This is also coupled with businessmodels that are evolving rapidly as organisationsmigrate to an increased reliance on Internet tech-nologies [ei]. These issues are exacerbated by thelack of effective design tools, as well as the nexttwo characteristics.

Short time frames for initial deliveryWeb development projects often have delivery

schedules that are much shorter than for conven-tional IT projects - often in the range of 1-3months. This is partly a consequence of the rapidpace of technological development and partly re-lated to the rapid uptake of Web systems.

Highly competitiveWeb projects tend to be highly competitive.

This is, of course, not new - being typical ofthe IT industry in general. The nature of thecompetitiveness is, however, somewhat different.There is regularly a perception that with simpleWeb authoring tools anyone can create an effec-tive site. This creates inappropriate expectationsfrom clients coupled with numerous small start-upcompanies claiming to be doing effective Web de-sign but in reality offering little more than HTMLskills and rudimentary graphic design. The resultis a highly uninformed competitiveness.

Fine-grained evolution and maintenanceWeb sites typically evolve in a much finer-

grained manner than conventional IT applications.The ability to make changes that are immediatelyaccessible to all users without their interventionmeans that the nature of the maintenance pro-cess changes. Rather than a conventional prod-uct maintenance / release cycle, we typically havean ongoing process of content updating, editorialchanges, interface tuning etc. The result is a muchmore organic evolution.

Given these unique characteristics of Web sys-

3

tems, we can investigate desirable changes in thedevelopment methods and processes. For eachof the different areas impacted, we will look ateach characteristic and consider how it is beingaddressed. We will begin by looking at changes inthe models and notations that are used to supportthe development of Web systems.

III. CHANGES TO MODELS AND NOTATIONS

Although Web systems can be viewed as soft-ware systems, this does not automatically implythat existing representations of various aspects ofthese systems will be able to be directly applied.Indeed, to blindly apply existing models to therepresentation of Web systems would encouragedevelopers to overlook the peculiarities of theseWeb systems, and hence not address these pecu-liarities, leading to inappropriate solutions.

This is not to say that existing models shouldnot be utilised - simply that we need to do sowith an awareness of their limitations with re-spect to the aspects of Web systems that we wishto understand and document. We also need tounderstand how these limitations may be circum-vented by appropriately supplementing (or replac-ing where necessary) the models. Let us look atthe unique characteristics of Web systems, includ-ing those discussed above, and consider the impactof each, in turn, on what we may wish to represent.

Link between business model and architectureThe impacts that Web systems have on busi-

ness models implies that there is a need to beable to understand (and document) the link be-tween business models and system architectures.This has typically been only implicitly addressedin traditional development as the business mod-els are well established and understood. This isless true for Web projects and, as a result wesee a growing body of work - largely emerg-ing from large technology vendors such as IBM,Sun and Microsoft - that considers how to repre-sent supported business functions and the techni-cal architectures required to support these. Themost mature of these approaches is the pat-terns for e-Business work being developed by IBM(see http://www.ibm.com/framework/patterns/).This work provides a framework for identifyingcommon patterns of business models. As statedin [7]:

Page 4: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

4 SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS, E-EDUCATION, AND E-SCIENCE

The paths to creating e-businesses are repeat-able. Many companies assume that they are uniqueand that therefore every creation of an e-businesshas to be learned as you go. In fact, there arelessons and architectural paths or patterns that canbe discerned from all these engagements.

For each business pattern, a number of logicalarchitectures (or topologies) are defined. Thesetopologies provide a mechanism for fulfillinga par-ticular business need. In effect, these models pro-vide a direct link between the business models thatunderpin the systems being developed and thetechnical architecture that supports these busi-ness models. One problem with these current ap-proaches is that the architectural models tend toemphasise functionality, with little considerationof how to represent the information architecture.In particular, aspects such as content modelling,information viewpoints etc. are not addressed.

Open modularised architecturesAlthough there is significant attention on mod-

elling of open and component-based systems, littleattention has yet been applied to considering themodelling of these systems in the context of theWeb.

Rapidly changing technologiesExcept where addressed peripherally, the rapid

pace of technological change is only poorly con-sidered. Indeed, the work on detailed design nota-tions for representing certain aspects of Web sys-tems (discussed in the next few points) may ac-tually create problems in terms of the portabilityof designs into new technologies. Alternatively,work on architectures and, more broadly, on in-formation models tends to create designs that areless dependant on specific technologies, and hencemore likely to be able to be adapted to changes.

Content is kingTh importance of content within Web sites im-

plies a need to at least consider how we under-stand and represent the informational elementsof a Web system. It is not surprising thereforethat that much of the earliest work on Web devel-opment models focused on information modellingand structuring.

Early approaches in this area evolved outof work on data modelling (such as Entity-Relationship models) and applied this to mod-

elling the information domain associated with ap-plications. Indeed, much of this work predates theWeb and focused on hypermedia design. For ex-ample RMM (Relationship Management Method-ology [S]) claims to provide a structured designmodel for hypermedia applications. In reality,the focus is very much on modelling the under-lying content, the user viewpoints onto this con-tent and the navigational structures that interlinkthe content. OOHDM (Object-Oriented Hyper-media Design Model um is a similar approach,though somewhat richer in terms of the informa-tion representations and based on object-orientedsoftware modelling approaches. Other similar ex-amples include EORM [10]and work by Lee [11].WSDM [12] attempts to model slightly differentcharacteristics - beginning more explicitly fromuser requirements, but these are only addressed ina very rudimentary fashion. In general, these no-tations were either developed explicitly for mod-elling information in the context of the Web, orhave been adapted to this domain.

More recently, work on both WebML (Webmodelling Language [13]) and the adaptation ofUML (Unified modelling Language [14] - anemerging industry standard for modelling object-oriented systems - see for example [15]) has be-gun to amalgamate these concepts into a richermodelling language for describing Web applica-tions. However, despite aims to support compre-hensive descriptions, the focus (as with the abovetechniques) is very much on content modellingrather than describing the functionality that is akey element of most current commercial Web sys-tems. This leads on to the next point.

Increased emphasis on user interfaceA key element of user interfaces is the function-

ality that they provide. A few attempts have beenmade to integrate information modelling conceptswith system functionality [16], [17]though in gen-eral these approaches are still rather simplistic,lack scalability and focus on low-level design rep-resentations. Conallen's [J 7] work in particular isinteresting insofar as it attempt to link a users'sview of the system (as seen through the interac-tion with Web pages) to the back-end processesthat support this interaction.

Other researchers have looked at modelling theway in which systems are utilised. For example

Page 5: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

LOWE AND HENDERSON-SELLERS: CHARACTERISTICS OF WEB DEVELOPMENT PROCESSES

Guell et al. [1~]extend OOHDM to include toolssuch as user scenarios and use cases. Vilain etal. [19] has adapted UML to representing user in-teractions. Other researchers have investigatedthe use of formal methods for representing naviga-tional requirements [20J or timing constraints [21]- though these tend to focus on ensuring consis-tency rather than directly addressing the qualityof the user interface.

Possibly the most fruitful work in this area is us-age centred design [:'.2], although a rigourous anal-ysis of the application of these techniques to Webdevelopment has yet to be carried out.

Increased importance of quality attributesAs with some other aspects, this has not been

directly addressed at a modelling level, exceptinsofar as developing effective architectures thatsupport characteristics such as robustness, scal-ability and reliability. Certainly these elementshave not been effectively woven into the detailedWeb requirements or design models.

Client uncertaintyClient uncertainty largely arises from a lack of

understanding of the business problems being ad-dressed by the Web systems and, as such, designprototypes on their own can play only a limitedrole. Nevertheless, some of the techniques men-tioned above that focus on modelling the way inwhich systems are utilised [J~~], [ 9] may help re-duce client uncertainty.

One avenue being pursued by the authors is theinvestigation of a characterisation model that rep-resents the key aspects that need to be woven intoan evolving specification of a Web system [23].This model highlights the links between the var-ious characteristics, especially including the linkbetween the business architecture and the techni-cal and information architectures. The intention isthat it be used to guide the formulation and eval-uation of project acceptance criteria, user require-ments and detailed contractual specifications.

Changing business requirementsThe points made in the above paragraph ap-

ply here as well. Furthermore, there is a beliefheld by some authors that configuration manage-ment must playa substantially increased role [21]- leading to some consideration of configurationmanagement models for Web systems.

5

Short time frames for initial deliveryThis is an issue that has yet to be effectively ad-

dressed in terms of how it impacts on Web designmodels and notations.

Fine-grained evolution and maintenanceAgain, this has yet to be considered in any sub-

stantial detail. It is worth pointing out, how-ever, that one aspect of modelling that activelyinhibits effective Web system maintenance is thelack of a cohesivearchitectural modelling languagethat actively links the information architecturewith the technical architecture [2;;]. Conversely,the information models (such as OOHDM [9J andWebML [U]) actively support a much clearer un-derstanding of the impacts of changes to variousaspects of the underlying content, viewpoints ornavigational structures.

IV. CHANGES TO THE PROCESS

Improving the modelling support for the uniquecharacteristics of Web systems is a useful first step- but, on its own, it is not sufficient. We alsoneed to consider how we actually carry out thedevelopment. This includes both the specific ac-tivities and tasks that are desirable, as well asbroader process issues related to how we organisethis work. We begin this section by looking brieflyat our previous work that has directly addressedexactly this issue.

A. Web OPEN

OPEN (Object-oriented Process, Environment,and Notation) is a process-focused methodolog-ical approach to software-intensive systems de-velopment useful for both object-oriented andComponent-Based Development (CBD). It is thelongest established of the third-generation 00 ap-proaches and covers the full development lifecy-cle, including business as well as software issues.OPEN was developed and is maintained by thenot-for-profit OPEN Consortium, an internationalgroup of methodologists, CASE tool vendors anddevelopers. OPEN was initially created by themerger of earlier methods: MOSES, SOMA, Fire-smith, Synthesis and enhanced by state of the artideas from BON, Ooram, UML etc. It is docu-mented in a series of books (e.g. [:2G], [:27], [:28],[2i)], [:50]) and in many journal articles, particu-larly in the journal JOOP. Many of these shorter

Page 6: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

6 SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS, E-EDUCATION, AND E-SCIENCE

articles are to be found on the OPEN web site athttp://www.open.org.au.

A unique aspect of OPEN is that it is not merelya process but a configurable family of processes,defined in terms of a metamodel (known as theOPEN Process Framework or OPF). This meta-model contains a number of major elements (Fig-ure 1) that can be multiply instantiated: workunits (such as activities and tasks); work products;and producers. From these instances of the pro-cess fragments, organisationally-specific processescan be readily constructed. The way these ele-ments are put together is also the decision of theorganisation or development team - thereby sup-porting the construction of highly customised de-velopment processes.

The component-based nature of OPEN permitsappropriate extensions to support developmentin new domains. One such set of extensions isthose for Web development, called Web OPEN(see Haire et al. [Tl] for a more complete treatmentofWeb OPEN). These extensions were derived pri-marily from an analysis of the documented differ-ences between web development and conventionaldevelopment, and validated using case studies ofcommercial Web development projects. It is worthnoting that many of the original (i.e. non web)activities, tasks, techniques and roles in OPENare still relevant to Web development. For exam-ple, the tasks relevant to the activities of ProjectInitiation, Implementation Planning and ProjectPlanning will remain relatively unchanged. Activ-ities such as Requirements Engineering and Sys-tem Build will be most affected, since this is wherethe project domain affects the process most notice-ably. During the remainder of the paper we shalluse Web OPEN to illustrate many of the ways inwhich the development process can be adapted tosuit Web development.

B. Required changes to the process

Again, we will consider each of the issues raisedpreviously and investigate how this might be ad-dressed by appropriate changes to the develop-ment process.

Link between business model and architectureAlthough the relationship between the business

model and the system architecture is beginning tobe addressed at a notational level, there is little

work in this area in terms of processes that sup-port the interpretation of business requirementsand the relationship that these have to the archi-tecture. The work that does exist tends to focuson the design of architectures (see the next point).One of the few exceptions is the IBM work onpatterns for e-Business that was mentioned previ-ously. Although not providing a formal process,it does suggest an implicit process whereby thebroad business needs are used to select a suitablebusiness pattern, and then to use this to guide theselection of suitable architectures.

Open modularised architecturesWeb systems are often constructed from multi-

ple COTS (commercial off-the-shelf) componentsthat are adapted and integrated together. Indeed,strong integration skills become much more crit-ical in most Web projects. The importance of astrong architectural design is also increased. In-deed, many see creating a solid architecture asthe most crucial component of a successful Websystems development.

Within Web OPEN, a specific task called De-sign web site architecture has been introduced.This can be supported, as indicated by the workon patterns, by the selection of suitable architec-tural pattern - formalised in a Web OPEN taskChoose architectural pattern for web site. TheComponent Based Development (CBD) additionsto OPEN [3:2] provide further useful support.

One aspect that is yet to be effectivelyaddressedis appropriate support (either as tasks or suitabletechniques) for the linking of the various disparateelements of the architecture (i.e. informationaland technical to the business architecture).

Rapidly changing technologiesApart from indirect support through aspects

such as the design of evolvable component-basedarchitectures and technology-independent datarepresentations, little consideration has been ex-plicitly given to the issue of coping with rapidlychanging technology.

Content is kingAs has been pointed out, Web systems are

largely about content! A web site that looks fan-tastic, and has sophisticated and powerful func-tionality will still be a failure if it does not haveadequate and appropriate content, together with

Page 7: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

LOWE AND HENDERSON-SELLERS: CHARACTERISTICS OF WEB DEVELOPMENT PROCESSES 7

LifecycleProcess

<>1..-

KEY WorkcreateActivity

~Products

D class ,<)

«' • help in

I aggregation 1..-building

I

~ I..nuses

association Task Technique1.*

Fig. 1SOME OF THE KEY ELEMENTS IN THE OPEN PROCESS FRAMEWORK.

mechanisms for ensuring that this content is bothaccessible and maintained effectively.

This raises the issue, in web development, of theideas of both content management and informa-tion personalisation. These both represent func-tionality that must be included in the majority ofweb projects today. Since these issues can be con-sidered to play an intricate part in the architectureof the solution, they should be actively addressedwithin the development process.

Approaches such as Usage Centred Design [:2::]provide some indications of suitable activities -though typically not as part of a broader frame-work. Web OPEN also addresses these issuesthrough three tasks. Two of these relate to theplanning stage: Design and implement contentmanagement strategy and Design and implementpersonalisation strategy, and one refers to the en-actment stage of project management: Undertakecontent management.

The actual authoring of the content itself is alsoa significant development issue that is often over-looked. With conventional software developmentthe population of the system with data is largelyviewed as an operational issue (or at best, part ofdeployment). With Web development, then gen-eration of "data" (i.e. content authoring) is fun-damentally part of the development process [:n]

- involving significant editing and layout of text,preparation of images and other media, obtain-ing copyright clearances etc. The developmentprocesses that underpin some of the informationmanagement approaches discussed earlier recog-nise this explicitly.

We need to ensure that content authoring is ap-propriately integrated into the development pro-cess. Web OPEN addresses this through the taskCreate content (on web site). In addition, muchcontent reuse is possible. Thus the techniqueReuse of graphical components is also available.One particularly useful form of reuse is that pro-vided by Web templates.

Increased emphasis on user interfaceThe development of the user interface raises nu-

merous issues. Let us begin by considering howcontent will be combined with the interface. Effec-tively this brings together content authoring andsoftware development or, more precisely, creativedesign and technical development. Web OPENaddresses this through the task Integrate contentwith user interface. It is worth noting that thishighlights the difficulties that occur when com-bining two different cultures together within thesame project.

We also need to consider the actual interfacedesign. The user interface within a web project

Page 8: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

8 SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS. E-EDUCATION. AND E-SCIENCE

constitutes a large portion of the overall project.It is vital in determining the success or failureof the project. OPEN has always had a tasknamed Design user interface. This task howeverhas been expanded within Web OPEN to incor-porate a number of relevant subtasks. These sub-tasks have been taken from Constantine and Lock-wood's work on Usage Centred Design (UCD) [:::2],which is more appropriate than the significantlydifferent User Centred/Centric Design. UCD fo-cuses on the work that users are trying to accom-plish and how the software will support this.

The three sub-tasks to the Design user inter-face Task that were introduced in Web OPEN [:il]are Create the UCD role model, create the UCDtask model, and Create the UCD content model.The last of these subtasks links in well with theTask Integrate content with user interface dis-cussed above, as it starts to identify the relation-ships between the content and the user interfaceincluding navigation maps (Task: Create naviga-tion map for web site). All three subtasks identifyhow the site is to be used (hence the name Us-age Centred Design) and also help to tie the userinterface to the web projects requirements.

Increased importance of quality attributesAs has been mentioned previously, Web systems

represent an increase in mission critical applica-tions that are often directly accessible to externalusers and customers. To address these, the pro-cess needs to explicitly address quality assurance(QA) issues. Some work has been carried out look-ing explicitly at quality assurance issues in Webdevelopment - though in general this has beenrestricted to specific domains such as educationalapplications [:;q.

One key element of effective QA is evaluation.Indeed, it has been claimed that the quality ofmultimedia projects are directly determined bythe effort put into evaluation [3;)]. For effectiveevaluation we need to establish suitable qualitycriteria - particularly in terms of how the Websystem will be actually tested against client re-quirements (OPEN Task: Define web site testingstrategy). This also implies the need to actuallyunderstand client requirements - an issue thatwe discuss further shortly.

Another important issue is the establishment ofsuitable standards in order to ensure consistency

- both from a usability perspective and from adevelopment perspective. With this in mind WebOPEN includes a task Define web site standards.It is worth noting that considerable attention isbeginning to focus on usability standards and,in particular, accessibility standards such as theWorld Wide Web Consortium's (W3C) Accessi-bility Initiative [36], [:ri].Client uncertainty andChanging business requirements

These two issues are so interrelated at a pro-cess level that we discuss them together. We be-gin by looking at how conventional software pro-cesseshandle requirements. Stated rather simplis-tically, they tend to assume that requirements areknown to clients, and simply need to be elicitedand analysed. These processes usually differenti-ate between user requirements (often formalisedin a URD - or User Requirements Definition)that capture the user understanding of their needs,and the system specification (SRS - or system re-quirements specification) that represents the sys-tem that will meet these needs. In effect, thetwo documents are different representations of thesame concepts. A typical process will be to elicitrequirements (which are documented in the URD)and then analyse these requirements in order toconstruct the SRS, iterating to refine the URD asnecessary.

One significant difficulty with this paradigm isthat it presumes that clients either understandtheir requirements, or at the very least under-stand the problem that is being addressed. Evenwhen clients are not able to articulate their re-quirements precisely, they are at least able to un-derstand whether a given design will address theirneeds. In cases such as these, the design may com-mence prior to full resolution of requirements. Thedesign will then be used to ascertain (from clientfeedback) whether the proposed solution addressesthe identified need.

This is problematic for Web projects, wheremany clients not only have a poor understandingof their requirements but also have a poor under-standing of the problems being addressed by theproposed system. In these circumstances, simplyusing a design to clarify whether it addresses theproblem will be insufficient, since the problem it-self is only poorly understood.

Page 9: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

LOWE AND HENDERSON-SELLERS: CHARACTERISTICS OF WEB DEVELOPMENT PROCESSES

As an illustrative example of these issues, con-sider the increasing use of lightweight developmentprocesses for software projects [:.\2'], [;9]. One ofthe approaches receiving the most attention is theuse of XP (eXtreme Programming) [11)]. XP isbased on the incremental development of partial(or 'spike) solutions that are used to subsequentlyresolve specific requirements. These spike solu-tions are then integrated into the evolving systemthrough refactoring of the current solution to in-corporate these components. When used in con-ventional software development XP has proven tobe effectivefor projects that are initially ill-defined- a characteristic of many web projects. As aresult, many of the proponents of XP and simi-lar approaches see it is an ideal approach to beadopted for Web development [1 I].

There are, however, certain problems that re-strict the applicability of approaches such as theseto Web projects. The first is that a number ofstudies (see, for example [iL2]) have shown thatapproaches such as XP only work effectively forprojects that have cohesive development teams.This is often not the case with Web projects,which often lack cohesiveness between the tech-nical development and the creative design as a re-sult of the disparate disciplinary backgrounds ofthe development team members. XP can also re-sult in a brittle architecture and poor documen-tation, which makes ongoing evolution of the sys-tem difficult - something that is important forWeb systems. Finally, and perhaps most funda-mentally, XP utilises partial solutions to resolveuncertainty in requirements, but does not inher-ently handle subsequent changes in these require-ments (i.e. requirements volatility) as the systemevolves. This creates problems for web systems,where the emerging design results in an evolv-ing client understanding of their needs, and hencevolatile requirements.

In effect, conventional software engineering pro-cesses see requirements as preceding and drivingthe design process. Even where an incrementalapproach (such as XP) or an iterative approach(involvingmultiple feedback loops) is adopted, thedesign is viewed as a way of assisting in the identi-fication and validation of requirements; yet rarelydoes it help the client to actually formulate theirneeds. In Web development, the situation is fun-

9

damentally different. The design process not onlyhelps developers and clients articulate their needs,but also helps clients understand the system do-main and therefore their needs.

In effect, the design partially drives the require-ments process. We begin with a poor client un-derstanding of their own needs (as well as systemcapabilities) and during the course of the projectthis understanding evolves and matures. This hasseveral consequences. The first is that it increasesthe importance of creating flexible solutions thatcan be updated and migrated to new technologieswith minimal effort. For example, the need forreusable data formats (such as XML) increasessubstantially. A second consequence is that de-velopers' understanding of these technologies isoften restricted, increasing project risks. To ad-dress these issues, Web OPEN includes the tech-nique Development spikes - though it needs tobe recognised that this is utilised somewhat differ-ently from the spikes in XP. Specifically,the spikesare used to help clients develop an understandingof the technology and support client understand-ing of the problem domain. Web OPEN also in-cludes the technique Field trips, which are usedto examine the current business environment andfinal place of deployment of the system - againwith the intention of improving both client anddeveloper understanding of the system context.

It is also worth looking briefly at the hourglassmodel of Web development [2:3] (see Figure 2).This model depicts what commonly happens inweb development projects. What is interestingabout this diagram is that there is no separatedesign phase that is presented to the customer.Rather it has been broken into two: high level de-sign concerned with the architectural structure ofthe solution and lower level detailed design con-cerned with the design of the architectural mod-ules. The first of these two, the high level ar-chitectural design, has been incorporated into therequirements elicitation or analysis phase of de-velopment. The latter of the two, detailed design,has been moved into the production or build phaseof development.

Short time frames for initial deliveryThe shorter development timeframe of Web sys-

tems has a number of implications. Firstly, itincreases the importance of incremental develop-

Page 10: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

10 SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS, E-EDUCATION, AND E-SCIENCE

,,\

\.I,,IIII,

--~---~.--------~~~----Initial Ddtailed

S[R!eifiCLlJign Spec:1ftcation-_..~-_____ I

-..._- ...)---_ .......••-I -.III

",/

,' ...-..... "", ,r ,, ,, ,, \, \

I ,

! /--\ \1_.:---\--t.-I I I~: \/-I '/1 I,~ ::I I ,II v I II """ I •!/\ , 1i \.,/ ;, ....•. ,

\ ,, ,\ ,, ,

\ ,\ r, ,

•.....__ .•.,'

BusinessRequirements

InitialVision

InceptionAnalysis & High

Level Design

CONTRACT PHASES• •

ArchitecturaSpecification

Prototypes(White Sites)

ContractualSpecification Detailed

DesignSpecification Implemented

System

•Detailed Design

& Build •Figure I: Contractual phases against the development process

Fig. 2THE HOURGLASS MODEL OF WEB SYSTEM DEVELOPMENT

ment approaches and consequently also increases(as discussed above) the reliance on flexiblesystemarchitectures (particularly with respect to the userinterface and the way in which information is man-aged within the site). Web OPEN addresses theseissues through the introduction of the activity Website Management. This brings together all the is-sues regarding the development, maintenance andmanagement of a corporate web site. The objec-tives of the web site management activity includescreating a high quality web site; keeping the website up to date; and ensuring that site standardsare met as the web site evolves.

Indeed, probably more importantly than the ac-tual tasks in Web OPEN is the flexible way inwhich processes can be constructed from the poolof tasks, activities, techniques, roles etc. This ap-proach allows processes to be highly customised tothe specific characteristics of the project - some-thing that is highly desirable when developmental

time pressures become a major issue.

Fine-grained evolution and maintenanceThe unique characteristics of Web system main-

tenance - and its impacts on the supportingprocesses - has only been very peripherally ad-dressed in the literature. Probably the most in-teresting avenue of work has been that related toConfiguration Management (CM). Dart [24] ar-gues that, because of the incremental nature ofWeb projects, and the fine-grained way in whichthey change, CM is even more important thanfor conventional projects. Only very rudimen-tary consideration is, however, given to the wayin which CM is integrated into the broader devel-opment process.

It is also useful to note that a consequenceof the emphasis on rapid development and fine-grained development is that there can tend to beless thought to formal evaluation as this is often

Page 11: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

LOWE AND HENDERSON-SELLERS: CHARACTERISTICS OF WEB DEVELOPMENT PROCESSES

perceived as interrupting the build process.One unusual area that has been used as an anal-

ogy for web development and may provide someuseful insights into maintenance processes is land-scape gardening [L;j. Web site development is of-ten about creating an infrastructure (laying outthe garden) and then 'tending' the informationthat grows and blooms within this garden. Overtime the garden (i.e. Web site) will continue toevolve, change and grow. A good initial architec-ture should allow this growth to occur in a con-trolled and consistent manner. This analogy hasbeen discussed in terms of providing insights intohow a site might be maintained.

V. CONCLUSIONS

In this paper we have analysed the differencesbetween Web systems and more conventional soft-ware and IT systems, focusing on the implicationsof these differences for the development of Websystems. In particular, we have investigated bothdesirable changes in the models and notations, andin the development processes.

The analysis has emphasised that althoughthere is an emerging body of research in this area,it is still relatively fragmented and considerablework still remains to be carried out. Several areasare worth highlighting. The first is the need for adesign-driven requirements process that structuresthe way in which design activities can be linked tothe clarification of requirements through an appro-priate model of domain uncertainty. The secondis an improved linkage between the representationof the architectural elements of a Web system. Inparticular, given the evolving role of designs, it isimportant that the business architecture be ableto be linked to both the information architectureand the technical architecture of a system. Indeeda fruitful area for further investigation is to lookat how the informational and functional aspectsof the architecture can be coupled appropriatelyduring the design.

One element driving both these research areas isour ongoing refinement of a characterisation modelthat captures the various elements that emerge inthe specification and design of Web sites. Thismodel provides a basis for understanding whichelements should be clarified at which point in theprocess, and the linkages between these elements.

11

ACKNOWLEDGMENTS

The authors wish to thank Brendan Haire for hisvaluable contributions in developing many of theWeb OPEN extensions described in this article.

The first author also wish to acknowledge thecollaborative funding support from the AustralianResearch Council, Access Online Pty Ltd and AI-lette Systems Ltd. under grant no. C4991-7612which partially supported this work. In particularwe wish to thank Vassiliki Elliott, John Eklund,Ross Jeffery, Nick and Marcus Carr, Louise Scott,Lucila Carvalho, and John D'Ambra for their con-tributions to this research project.

This is Contribution number 01/10 of the Cen-tre for Object Technology Applications and Re-search.

REFERENCES

[1] J. Burdman, Collabomtive Web Development, Addison-Wesley, 1999.

[2] E. England and A. Finney, Managing Multimedia: ProjectManagement for Intemctive Media, Addison-Wesley, 2ndedition, 1999.

[3] S. Overmyer, "What's different about requirements engi-neering for web sites?," Requirements Engineerng Journal,vol. 5, no. 1, pp. 62-65, 2000.

[4] P. Russell, "Infrastructure - make or break your e-business," in TOOf.,S-Pacific 2000: Technology of Object-Oriented Languages and Systems, Sydney, Australia, 2000.

[5] G. Sinha, "Build a component architecture for e-commerce," e-Business Advisor, 1999.

[6] 1. Stein, "Profit, the prime directive," WebTechniques,vol. 5, no. 11, pp. 14-17,2000.

[7] J. Lord, "Patterns for e-business: Lessons learned frombuilding successful e-business applications," June 2000.

[8] T. Isakowitz, E. Stohr, and P. Balasubramanian, "Rmm:A methodology for structured hypermedia design," Com-munications of the ACM, vol. 38, no. 8, pp. 34-44, 1995.

[9] D. Schwabe and G. Rossi, "The object-oriented hyperme-dia design model," Communications of the ACM, vol. 38,no. 8, pp. 45---46,1995.

[10] D. Lange, "An object-oriented design method for hyper-media information systems," in HICSS-27: Proc of theTwenty Seventh Hawaii International Conference on Sys-tem Sciences, Maui, Hawaii, 1994.

[11] S. Lee, "A structured navagation design method for in-tranets," in Third Americas Conference on InformationSystems, Association for Information Systems (AIS), Indi-anapolis, 1997.

[12] O. De Troyer and C. Leune, "Wsdm: A user-centereddesign method for web sites," in 7th International WorldWide Web Conference, Brisbane, Aust, 1997.

[13] S. Ceri, P. Fraternali, and A. Bongio, "Web modelinglanguage (webml): a modeling language for designing websites," in Proceedings of WWW9 Conference, Amsterdam,2000.

[14] "OMG unified modeling language specification, version1.3," OMG document 99-06-09, June 1999.

[15] H. Baumeister, N. Koch, and L. Mandel, "Towards a umlextension for hypermedia design," in UML 1999, 1999, pp.614-629.

Page 12: Characteristics ofWeb Development Processes · Characteristics ofWeb Development Processes David Lowe, Brian Henderson-Sellers Abstract-The nature of Web system develop-ment is significantly

12 SSGRR-2001: INFRASTRUCTURE FOR E-BUSINESS, E-EDUCATION, AND E-SCIENCE

[16] K. Takahashi and E. Liang, "Analysis and design of web-based information systems," in 7th International WorldWide Web Conference, Brisbane, Aust, 1997.J. Conallen, Building Web Applications with UML, Addi-son Wesley Object Technology Series. Addison-Wesley, 1stedition, 1999.N. Guell, D. Schwabe, and P. Vilain, "Modeling interac-tions and navigation in web applications," in Proceedingsof the World Wild Web and Conceptual Modeling '00 Work-shop - ER '00 Conference, Salt Lake City, USA, 2000.P. Vilain, D. Schwabe, and C. S. d. Souza, "A diagram-matic tool for representing user interaction in uml," inUML'2000, York, U.K., 2000.D. German and D. Cowan, "Formalizing the specificationof web applications," Lecture Notes in Computer Science,Springer Verlag, vol. 1727, pp. 281292, 1999.F. B. Paulo, M. Augusto, S. Turine, M. C. F. d. Oliveira,and P. C. Masiero, "Xhmbs: A formal model to supporthypermedia specification," in Ninth ACM Conference onHypertext, 1998, p. 161170.L. Constantine and L. Lockwood, Software For Use,Addison-Wesley, 1999.D. Lowe, "A framework for defining acceptance criteria forweb development projects," in Second ICSE Workshop onWeb Engineering, S. Murugesan, Ed., Limerick, Ireland,2000.S. Dart, Configuration Management: The Missing Link inWeb Engineering, Artech House, 2000.D. Lowe and V. V. Elliott, "Web requirements: Anoverview," Journal of the American Society for Informa-tion Science and Technology (JASIST), Submitted.I. Graham, B. Henderson-Sellers, and H. Younessi, TheOPEN Process Specification, Addison-Wesley, 1997.B. Henderson-Sellers, A. Simons, and H. Younessi, TheOPEN Toolbox of Techniques, Addison-Wesley, UK, 1998.D. Firesmith, G. Hendley, S. Krutsch, and M. Stowe,Object-Oriented Development Using OPEN: A CompleteJava Application, Addison-Wesley, Harlow, UK, 1998.B. Henderson-Sellers and B. Unhelkar, OPEN Modelingwith UML, Addison-Wesley, Harlow, UK, 2000.D. Firesmith and B. Henderson-Sellers, The OPEN Pro-cess Framework. An Introduction, Addison-Wesley, Har-low, UK, 2001.B. Haire, B. Henderson-Sellers, and D. Lowe, "Supportingweb development in the open process: additional tasks,"in COMPSAC'2001: International Computer Software andApplications Conference, Chicago, Illinois. USA, Submit-ted, IEEE Computer Society.B. Henderson-Sellers, "An open process for component-based development," in Component-Based Software En-gineering: Putting the Pieces Together, G. Heineman andW. Councill, Eds. Addison-Wesley, Reading, MA, USA,2001.A. Ginige, D. Lowe, and J. Robertson, "Hypermedia au-thoring," IEEE Multimedia, 1995.J. Eklund and D. Lowe, "A quality assurance methodologyfor technology-delivered education and training," in Web-Net 2000: World Conference on the WWW and Internet,G. Davies and C. Owen, Eds., San Antonio, Texas, USA,2000, pp. 162-169, AACE: Association for Advancement ofComputing in Education.R. Philips, The developer's handbook to interactive multi-media, Kogan Page. London., 1997.J. White, W. Chisholm, and G. Vanderheiden, "Web con-tent accessibility guidelines 2.0," World Wide Web Consor-tium, Workig Draft WD-WCAG20-20010125, Jan. 2001.W. Chisholm, G. Vanderheiden, and I. Jacobs, "Techniquesfor web content accessibility guidelines 1.0," World Wide

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

Web Consortium, Note WAI-WEBCONTENT-TECHS-19990505, May 1999.E. Angelique, "A lightweight development process for im-plementing business functions on the web," in WebNet'99,Honolulu, Hawaii, USA, 1999, pp. 262-267.R. Fournier, Methodology for Client/Server and Web Ap-plication Development, Yourdon Press, 1999.K. Beck, Extreme Programming Explained, Addison-Wesley, 1999.D. Thomas, "Managing software development in web timesoftware," in XP2000, Cagliari, Italy, 2000.R. Martin, "A case study of xp practices at work," inXP2000, Cagliari, Italy, 2000.D. Lowe, "Web engineering or web gardening?," WebNetJournal: Internet Technologies, Applications and Issues,vol. 2, no. 1, Jan-Mar 2000.

[39]

[40]

[41]

[42]

[43]

Associate Professor David Lowe is theDirector of Undergraduate Programs in theFaculty of Engineering, and a Co-Directorof the Centre for Object Technology, Ap-plications and Research (COTAR) at theUniversity of Technology, Sydney. He hasactive research interests in the areas of Webdevelopment and technologies, hyperme-dia, and software engineering. In particularhe focuses on Web development processes

and web project specification and scoping, and information con-textualisation. He has published widely in the area, includingseveral texts (Lowe and Hall, Hypermedia and the Web: AnEngineering Approach, Wiley, 1999 and Wilde and Lowe, Tran-scluding the Web: Linking and XML, Addison-Wesley (cur-rently in preparation». In the last 7 years he has publishedover 40 refereed papers and attracted over $ 900,000 in funding,including a recent grant for research into Web project specifi-cations. He is on numerous Web conference committees andis the information management theme editor for the Journalof Digital Information. He has undertaken numerous consul-tancies related to software evaluation, Web development (espe-cially project planning and evaluation) and Web technologies.A/Prof Lowe can be reached at The University of Technology,Sydney; P.O. Box 123, Broadway, NSW 2007, Australia. Tele-phone +61-2-95142526; Email: [email protected].

Professor Brian Henderson-Sellerswas the first Director of CO TAR (1994-6, 1999-present) and is Professor of Infor-mation Systems at the University of Tech-nology, Sydney. His interests are mainlyin 00 methodologies and process, metrics,project management and company migra-tion to 00. He is involved in several met-rics projects, leads the OPEN Consortiumand is involved, through the Object Man-

agement Group, with the ongoing changes to UML and thenew initiative towards a Software Process Engineering Model(SPEM) standard. He has published a significant number ofpapers and books under the auspices of COTAR as well asmaking a large number of international presentations. He isa columnist for the large circulation 00 journal JOOP and afrequently invited speaker at industry conferences. ProfessorHenderson-Sellers can be reached at The University of Technol-ogy, Sydney; P.O. Box 123, Broadway, NSW 2007, Australia.Telephone +61-2-9514-1687; Email: [email protected].


Recommended