A Web-Centred Approach to End-User Software...

36

A Web-Centred Approach to End-User Software Engineering

DAVID LIZCANO, Universidad a Distancia de Madrid, UDIMAFERNANDO ALONSO, JAVIER SORIANO, and GENOVEVA LOPEZ, Universidad Politecnicade Madrid

This article addresses one of the major end-user software engineering (EUSE) challenges, namely, how tomotivate end users to apply unfamiliar software engineering techniques and activities to achieve their goal:translate requirements into software that meets their needs. EUSE activities are secondary to the goal thatthe program is helping to achieve and end-user programming is opportunistic. The challenge is then to findways to incorporate EUSE activities into the existing workflow without users having to make substantialchanges to the type of work they do or their priorities. In this article, we set out an approach to EUSE for web-based applications. We also propose a software lifecycle that is consistent with the conditions and priorities ofend users without programming skills and is well-aligned with EUSE’s characteristic informality, ambiguityand opportunisticness. Users applying this lifecycle manage to find solutions that they would otherwise be un-able to identify. They also develop quality products. Users of this approach will not have to be acquainted withsoftware engineering, as a framework will take them through the web-centred EUSE lifecycle step-by-step.We also report a statistical experiment in which users develop web software with and without a frameworkto guide them through the lifecycle. Its aim is to validate the applicability of our framework-driven lifecycle.

Categories and Subject Descriptors: D.2 [Software Engineering]; D.3 [Programming Languages]; H.5[Information Interfaces and Presentation]; K.4 [Computers and Society]; J.4 [Social and Behav-ioral Sciences]

General Terms: Human Factors, Languages, Experimentation, Design, Reliability

Additional Key Words and Phrases: End-user programming, end-user development, visual programming,human-computer interaction

ACM Reference Format:Lizcano, D., Alonso, F., Soriano, J., and Lopez, G. 2013. A web-centred approach to end-user software engi-neering. ACM Trans. Softw. Eng. Methodol. 22, 4, Article 36 (October 2013), 29 pages.DOI: http://dx.doi.org/10.1145/2522920.2522929

1. INTRODUCTION

The breach between software development by end users (users without programmingskills) and professional developers is growing every year [Scaffidi et al. 2005]. Accord-ing to the US Bureau of Labor and Statistics there will be fewer than three millionprofessional programmers in the United States by early 2013, as opposed to more than55 million end users using spreadsheets and databases at work, many writing formulas

This work was partially supported by the EU co-funded IST projects FAST: Fast and Advanced StoryboardTools (GA FP7-216048), FI-WARE: Future Internet Care Platform (GA FP7-285248), and 4CaaSt: Buildingthe Platform as a Service of the Future (GA FP7-258862).Authors’ address: D. Lizcano, Universidad 3 Distancia de Madrid, UDIMA, via Servicio, No15, ColladoVillalba 28400, Madrid, Spain, email: [email protected]; F. Alonso, J. Soriano, and G. Lopez, School ofComputing, Universidad Politecnica de Madrid, Boadilla del Monte, Madris, Spain. Correspondence email:[email protected] to make digital or hard copies of part or all of this work for personal or classroom use is grantedwithout fee provided that copies are not made or distributed for profit or commercial advantage and thatcopies show this notice on the first page or initial screen of a display along with the full citation. Copyrights forcomponents of this work owned by others than ACM must be honored. Abstracting with credit is permitted.To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of thiswork in other works requires prior specific permission and/or a fee. Permissions may be requested fromPublications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212)869-0481, or [email protected]© 2013 ACM 1049-331X/2013/10-ART36 $15.00

DOI: http://dx.doi.org/10.1145/2522920.2522929

ACM Transactions on Software Engineering and Methodology, Vol. 22, No. 4, Article 36, Pub. date: October 2013.

36:2 D. Lizcano et al.

and dashboards to support their job [Scaffidi et al. 2005]. This has spawned a lot ofinterest in researching all aspects of software development by end users (EUD) anduser-centred software engineering.

ISO/IEC/IEEE 24765-2010 defines software engineering (SE) as “the application ofa systematic, disciplined, quantifiable approach to the development, operation, andmaintenance of software”. This is also applicable to end-user software development.Whereas end-user SE (EUSE) also involves systematic and disciplined activities thataddress software quality issues, these activities are secondary to the goal that theprogram is helping to achieve [Lieberman et al. 2006, Burnett et al. 2004; Myers et al.2008; Ko et al. 2011]. The key difference between professional and end-user SE isthe amount of attention given to software quality concerns. Because their prioritiesdiffer and end-user programming is opportunistic [Brandt et al. 2008], people whoengage in end-user programming seldom have time for or any interest in systematicand disciplined SE activities.

End users build their own software solutions in many domains, but the Web is theplatform that has come to dominate the end-user development scene over recent years.EUSE is starting to evolve with a vengeance in this domain [Little et al. 2007; Macıasand Paterno 2008; Nichols and Lau 2008; Toomim et al. 2009]. This is probably dueto the upsurge in web-based computing, as well as the SaaS (software as a service)philosophy adopted by major software companies that commercialize their products asweb resources.

This interest in EUSE applied to the Web has gone hand in hand with a substan-tial proliferation of web development tools for end users, like iGoogle, Yahoo! Dapper,Yahoo! Pipes, OpenKapow, RoboMaker, Netvibes, PageFlakes, JackBe, M2O, AMICO,Marmite, EzWeb, QedWiki, etc. But these tools do not see end users all the way throughthe software lifecycle [Ko et al. 2011; Burnett et al. 2004; Lieberman et al. 2006;Holtzinger 2005]. As a result, end users find it hard to create a working web applica-tion that meets their needs [Rosson et al. 2005; Burnett et al. 2003].

Considering that they are unfamiliar with programming and SE, all end users,and especially end users building web-based applications, have need of a softwaredevelopment lifecycle and lifecycle support tool. This software development lifecycleshould provide end users with guidelines, heuristics and steps to help them achievetheir goal of developing their own software solutions.

A number of outstanding EUSE research articles [Lieberman et al. 2006; Burnettet al. 2003, 2004; Myers et al. 2008; Ko et al. 2009], especially work by [Ko et al.2011], provide a very comprehensive picture of the state of the art in this new SEfield. Researchers have identified problems, such as end users being unconcerned withspecifications, design, testing and debugging; finding it hard to map requirements intosoftware that meets their needs; having little interest in encouraging and facilitatingreuse and especially in how to improve the quality of the product that they build; apartfrom other problems deriving from the actual problem domain. All these problems existin the web field, too. They need to be solved if end users are to be efficient developers.

In this article, we set out an approach to web EUSE, proposing a software lifecyclethat is consistent with the conditions and priorities of end users without programmingskills. Users will not have to be acquainted with SE, as a framework will take themthrough the web-centred EUSE lifecycle step by step. The aim is to solve one of themajor EUSE challenges, which is to motivate end users to apply unfamiliar SE tech-niques and activities to rapidly build a program to meet their needs and stay focusedon their primary goal, while still achieving software quality.

The article is organized as follows. Section 2 presents the state of the art in EUDand EUSE. Section 3 describes our WEUSE (End-User Software Engineering for Web)lifecycle, including examples of how a framework can support each SE stage. In this


A Web-Centred Approach to End-User Software Engineering 36:3

case, we use the FAST framework developed as part of a European Seventh FrameworkProgramme (FP7) project, called Fast and Advanced Storyboard Tools [FAST Project2011]. Section 4 describes a statistical experiment in which users undertake web soft-ware development with and without a framework to guide them through the lifecycle.Section 5 describes how the method used in FAST actually works and the characteris-tics required of web components that are to be implemented in a framework to supportthe lifecycle. Section 6 outlines the conclusions and future research lines.

2. RELATED WORK

There are several approaches targeting nonprogramming end users who are experi-enced in the problem domain. These approaches are designed to help them to develop[Obrenovic and Gasevic 2009] or adapt [Wulf et al. 2004] software for their own use.Most approaches focus on spreadsheet-based applications [Galleta et al. 1996; Panko1995]. Additionally, they are not good enough for end users to develop anything butstraightforward applications.

End users know what to do but not how to do it. On this ground, most research in thisarea applies declarative development technologies and, specifically, component-basedprogramming and visual composition techniques. This way, users can understand anduse, without actually having to build, such components. We think that this is the bestapproach for casual RIA development.

McIlroy [1968] first stated the need for component-based systems in the field ofSE. According to McIlroy, such component-based systems should adopt manufacturingindustry techniques, such as the use of black boxing, subassemblies and variability.Back boxing assures that a component has a well-defined interface and is built andtested according to a specification that can be documented as part of a componentscatalogue. Subassemblies are collections of related components that can be used jointly.Variability refers to the ease with which models or sizes of standard components canbe selected [Mørch et al. 2004].

Kay [1977] put forward the idea of using domain-specific visual components to em-power end users with computer applications. Henderson and Kyng [1991] further de-veloped this idea and demonstrated that components architectures were suitable forbuilding adaptable and parameterizable applications that can be modified using visualcomponents programming [Szyperski 1998] or programming by modification of exam-ples [Nardi 1993]. Stiemerling [2000], Stiemerling and Cremers [2000], Mørch et al.[2004] and Wulf et al. [2004] explored this angle. The goal was to execute compositeapplications developed by professional software engineers by retaining the componentsarchitecture design and creating frameworks to enable end users without programmingskills to tailor such applications using visual techniques. Although these proposals onlyallow end users to design and implement software using full off-the-shelf solutions, theyprovide, together with research reported in Wulf et al. [2008], the following lessons.

—Employing hierarchically nested component structures can give end users increasingcontrol over their applications [Won et al. 2006].

—Assembling components is a complex task that requires a visual component integra-tion formalism in order to validate the integration carried out at data type level anda level closer to the domain expert, where data semantics are compared.

—For end users to be able to develop composite applications, a components model hasto be defined with visual techniques that users use to interconnect such components.

In any case, all listed papers have two limitations. First, users cannot undertakeanything but a straightforward design by themselves because they do not know howto set forth their requirements and needs as components and would not be able to findthe right components. Second, users cannot extend the functionality of a component or



solution without resorting to low-level programming, for which they are not qualified.Both limitations lead to the same problem: end users are unable to enact a softwaredevelopment lifecycle, progressing naturally from requirements to a gradually moredetailed composite design with increasingly lower-level components until they manageto build their final solution. This goal calls for EUSE, which, for Web end users con-cerned with the composite creation of Web applications, should define specific activitieswithin the software lifecycle and specifications for a support tool to guide users throughthis lifecycle.

Some component-based SE papers, such as Heineman and Councill [2001] and Ning[1997], analyse how the software lifecycle should be tailored to build composite ap-plications. However, they all design a lifecycle for professional developers and not forend users specifically concerned with building Rich Internet Applications. There is notool to guide end users through the development of their solution from start to finish.There is, however, some research defining RIA design and implementation problemsand providing a host of visual languages and composition techniques [Newman et al.2003; Lin and Landay 2008; Bolin et al. 2005]. Only in the spreadsheet domain havethere been attempts at specifying an end-user lifecycle and support tools [Rothermelet al. 2001; Burnett et al. 2002]. Our research has adapted these ideas on EUSE tocomposite RIA development based on earlier work on spreadsheets. For this purpose,we conducted the following study of EUSE as a starting point for our research.

Background in End-User Software Engineering

Traditional SE activities related to EUSE in the field of spreadsheets, including re-quirements, design and specification, reuse, testing and verification, debugging andmaintenance, are introduced and discussed in Ko et al. [2009, 2011] and Burnett et al.[2003]. The implementation activity is discussed in Sutcliffe and Mehandjiev [2004],Kelleher and Pausch [2005], and Lieberman et al. [2006]. These studies have servedas the basis for our web-centred EUSE approach. Additionally, most EUSE researchsets out to be independent of purpose, even though the use and development of end-user programs depend largely on the purpose for which they are built [Ko et al. 2009].Regarding this point, we believe that EUSE for the web cannot be conceived as beingexactly the same as for other types of office applications like spreadsheets.

Table I summarizes the activities documented to date in EUSE research, the prob-lems they pose and problem-solving approaches.

There is no specific proposal of a defined lifecycle, containing a formalized scheduleof activities, tasks, artefact creations, etc. in the EUSE field. In this article, we proposea specific lifecycle, based on traditional SE activities but tailored to the problems ofweb end users. To solve the problems that end users will face in each activity, we usea framework providing guidance for end users that exploits most of the ideas specifiedin Table I.

3. A LIFECYCLE FOR WEB APPLICATION DEVELOPMENT BY END USERS

The state of the art suggests that end users find it hard to build their own web solutionusing current development tools. Our working hypothesis is that there is a need foruser-centred component-based technology, and an end-user SE lifecycle and supporttool using available technology to guide end users, step by step, through this lifecycle.Thus, end users could implement web applications that support their routine activ-ities. The support tool that we use is FAST. FAST is an assistant with a workflowengine to guide users through the proposed cycle. FAST recommends how to translaterequirements to specific components in each activity, how to adapt or create such com-ponents and how to create valid syntactic and semantic dataflows among components.To do this, FAST has: (a) a knowledge base composed of ontologies proper to several



Table I. EUSE Activity, Problems and Proposed Problem-Solving Approaches

EUSE activity Problems for end users Existing approachesRequirements End-user developers do not usually specify

or describe requirements. They regard thisas unnecessary effort because they aregoing to do the development. This causesproblems throughout the remainder of thedevelopment process [Costabile et al. 2006;Fischer and Giaccardi 2006; Mørch andMehandjiev 2000; Segal 2007]

Use special-purpose questions or asimilar mechanism to elicitrequirements [Ko and Myers 2004;Obrenovic and Gasevic 2009; Burnettet al. 2002]

Design andSpecification

The step from a list of requirements to adesign and specification that meets them isthe trickiest part of SE and is even morecomplicated in the end-user domain, whereusers without programming skills areunfamiliar with the techniques andheuristics that they can use to perform thisstep [Burnett et al. 2004; Obrenovic andGasevic 2009; Ko et al. 2011]

Provide a user-comprehensiblespecification language, using aninterpretation of user naturallanguage until an acceptable solutionhas been specified or use WYSIWYG[Lin and Landay 2008]Use a predefined set ofdesign/specification components orelements [Rode et al. 2005]Exploit programming by example(PbE) [Nichols and Lau 2008;Blackwell 2002]Engage an external programmer[Brandt et al. 2008]

Reuse It is easier to build a new product byreusing other users’ solutions than fromscratch [Ko et al. 2011]. Reuse is oftenprecisely what results in a satisfactorysolution [Blackwell 2002; Nichols and Lau2008]. But end users find it hard to reuseand adapt a solution built for one problemdomain for another purpose [Mackay 1990]

Use catalogues of solutions orbuilding blocks accompanied bysearch and recommendationmechanisms to help users tounderstand and use solutionscreated by others in a specific domain[Ko et al. 2011]Use tailoring mechanisms that havemodular or component-based codethat is easy to reassemble orparameterize [Mørch et al. 2004]

Implementation Users without programming skills cannotperform this activity [Sutcliffe andMehandjiev 2004]

Use either software reuse and/ordesign activities for implementationpurposes [Kelleher and Pausch 2005;Lieberman et al. 2006]

Testing andVerification

End users are not specifically trained toperform tests and detect errors. One of themajor causes of poor quality end-userdevelopments is end-user overconfidence inthe solution.

Use systematic testing tools, [Davis1996; Chambers and Erwig 2009],WYSIWIG white-box testing orpartial prototype validations usingboundary value analysis [Rothermelet al. 2001; Burnett et al. 2002,Igarashi et al. 1998; Clermont 2003;Fischer and Giaccardi 2006].Automatically compare the solutionspecification against the resultgenerated by users with unitinference and checking systems[Chambers and Erwig 2009]

Debugging End users get their program running assoon as possible. This ends up generatingother errors [Chambers and Erwing 2009].

Use a wizard to manage control anddata dependencies [Janner et al.2009]Provide social and collaborativesupport by a community of end usersthat share solutions or parts ofsolutions [Fischer and Gaccardi2006]



problem domains, including component semantics and data in order to recommendvalid dataflows; (b) a folksonomy created socially by end users (and enriched as a re-sult of end user FAST use) in order to recommend related components and assembliesused in other developments, and (c) a components catalogue describing componentfunctionalities. The details of this assistant, its internal behaviour, natural languageprocessing techniques, etc. are detailed later.

Studies by Ghezzi et al. [2002] suggest that the waterfall lifecycle model is lesssuitable in the end-user field than in professional development (where it also has a lot ofdetractors). Based on this study, we propose an iterative and incremental developmentmodel which exploits the provisionality described by Green et al. [2006]. Taking up thisidea, we suggest that users should divide their solution into parts in order to reduceproblem complexity.

Our lifecycle is a basic programming-in-small approach where software developmentis driven by use cases [Jacobson et al. 1999]. WEUSE starts with a statement describ-ing the solution, explicitly drafted by the user as a storyboard of the solution [Diethelmet al. 2005]. This statement, defined by users during requirements capture, drives firstthe analysis and then the design and implementation activities, which are closely inter-related and take advantage of many of the ideas proper to agile software developmentmodels [Beck 2000]. The result is a top-down software lifecycle approach, where suc-cessive incremental design-implementation iterations follow on from the initial userstatement during which existing components are searched and then visually composedusing increasingly finer-grained components.

This lifecycle is divided into a set of phases aligned with the end-user work method(top-down approach) described in Section 3.2. Each phase is composed of one or moreiterations through the defined set of activities described in Section 3.1. Each phaseis incrementally based on the results of the preceding phase. Users work on a finer-grained component type than in the previous iteration. The developed software is testedin each iteration so that users can gradually verify and validate their web application.The software development lifecycle concludes with the deployment of the executableweb solution for routine use by users.

3.1. End-User Software Engineering Lifecycle Activities

Table II summarizes the SE activities that our approach addresses and how they relateto the life-cycle phases described in the Section 3.2. Dataflow specification is a cross-life-cycle activity related to data semantics and data linking designed to build a dataflowamong components, which runs parallel to all other lifecycle activities.

The following is a description of how to use FAST to develop each activity.

—Requirements. Users have to explicitly state what solution they are looking for innatural language. The FAST framework parses the statement using NPL techniquesand analyses possible keywords. It uses these keywords to search a set of off-the-shelfcomponents possibly of interest to users. This is one way of guiding users throughthis activity, but any of the other approaches for moving from requirements to designdescribed in the state of art can be implemented.

Figure 1 shows how FAST recommends components for the problem stated byusers. Users enter the problem description at the bottom of the screen. The frame-work then uses context information, information on use by other users and compo-nent catalogue data to provide advice on how to tackle the part of the problem thatreturns most results and on which components they should analyse for use to designtheir solution.

—Analysis. Users use data supplied by the framework (see right side of Figure 1)to analyse the components recommended in the requirements activity and rework



Table II. Activities of the WEUSE

WEUSE Phase with greatestactivities Explanation activity workloadRequirements End users identify the problem from a

system-external viewpoint, producing anatural-language specification of problemrequirements. End users divide the probleminto smaller subproblems to be solved in eachiteration.

Inception

Analysis End users formulate a narrative description ofthe solution from the system-internalviewpoint. They try to map specificcomponents to parts of the target solution.

Inception and Elaboration

Design andImplementation

End users search for suitable web componentsfor their solution, which they link byperforming design tasks. If the targetcomponent does not yet exist, this or a similarcomponent is designed using finer-grainedcomponents.

Elaboration andConstruction

Testing End users verify that the provisional designsoutput in design and implementation activitieswork properly and validate the parts alreadyimplemented as a group.

Construction

Sharing andDeployment

End users publicize a composite application orcomponent that they have built across theentire end-user community for execution onsome target platform.

Transition

DataflowSpecification

Cross-lifecycle activity in which end userscreate dataflows generated and consumed bythe components based on their semantics(defined by a problem domain ontology). Endusers link lower-order element flows to createhigher-order components, provided that dataare of the same type and have the samemeaning. Additionally, components can beimported from other problem domains forreuse in the current domain to make moresense of the managed data.

Elaboration andConstruction

the narrative description of the solution based on suitable components that theyhave already identified. To do this, the framework recommends other componentscommonly used in combination with the components selected by users. This approachwas proposed by Wiedenbeck [2005].

—Design and Implementation. Based on the narrative description output in the analy-sis activity, the FAST framework recommends finer-grained components associatedwith the target dataflow. In other words, FAST recommends components that gen-erate or consume the data types described in the selected components and/or datatypes specified in the problem statement.

Figure 2 shows FAST guiding the user through a compositional development us-ing a specific mashup development tool (EzWeb). FAST recommends (left side) newcomponents that produce the data required by the current development and newcomponents (right side) that consume the data generated at this point in the designand related to the problem requirements. Users selected all these components in theanalysis activity. Additionally, FAST uses different colours to highlight the differentdata types in the current design to guide users through the visual creation of se-mantically valid dataflows. The semantics and the inference model used by FAST for



Fig. 1. FAST framework guiding users through the requirements activity.

Fig. 2. FAST framework guiding users through the design, visual composition and data linking tasks.

recommending components, checking dataflow validity, etc. is explained in detail inSection 5.2.

—Testing. FAST guides users through the testing of each dataflow created amongcomponents in the design and implementation activity and asks users what standarddata the application is to handle. These data will be used to create test benches.

Figure 3 shows FAST guiding end users through the white-box testing of an ele-ment based on its finer-grained components, itemized on the left of the screen.



Fig. 3. FAST framework guiding users through the new component testing task.

These components are taken from a catalogue that also includes test data forvalidating each individual component. Helpful details on the dataflow designed byusers, the meaning of the data in the current context and test data for the createdcomponent (users are asked to provide standard problem domain data) are shown atthe bottom. In the middle of the screen, a visual code (the colour red) indicates thecomponents that do not pass the tests. These components cannot be executed with-out additional components or require other operators to correct the target dataflow.Another visual code (the colour green) indicates which components are already re-ceiving the data that they require to perform their function and perform this functioncorrectly, that is, generate the expected values for the respective component type.

—Sharing and Deployment. The FAST framework provides a wizard that takes usersthrough the deployment of the software on some of today’s runtime EUD tools, suchas Yahoo! Pipes & Dapper, EzWeb or iGoogle, that is, through the process of addinga natural language description of the solution, how it works, what data it managesand the target results. In this way, FAST checks that the published component isparameterizable and can be tailored to other domains, an issue addressed by Dittrichet al. [2006].

—Dataflow Specification. The FAST framework uses ontologies from several problemdomains to determine the data semantics and guide users through this activity. Ituses visual elements (boxes that are coloured according to data types) to display thetypes of component input and output data for users. When users select an input andoutput data item, the framework visually highlights other inputs and outputs thatare compatible with this data type.

The following algorithm illustrates the iterations of the development lifecycle. Thisalgorithm governs the FAST framework workflow.



As already mentioned, users will use increasingly finer-grained components ineach iteration. To do this, visual components should be ordered hierarchically, wherethe top components can be composed from the next ones down and so on.

The lifecycle includes four web component levels: full solutions, web mashups,workspaces and widgets. Thanks to these composition levels, users can divide theirproblem spatially (into workspaces) and temporally (into dataflows among widgets) andalso rely on full solutions and separate mashups. These are very common componentsin today’s composite web applications [Lizcano et al. 2011a].

—A full solution is a composite web application shared by a user or supplier. Parametersand dataflows can be adjusted to adapt the solution to each problem domain. A fullsolution is composed of one or more mashups. A web application for making travelarrangements and bookings, a composite application for providing citizen supportwith public administration procedures, etc. are examples of full solutions.

—A mashup is a mixture of elements connected by a dataflow and organized asworkspaces, like spreadsheets, to perform a complex functionality. In particular, webmashups integrate heterogeneous data, application logic, and UI components (called



widgets) sourced from the Web to create new coherent and value-adding compositeweb applications. The part of the travel arrangements solution dealing with flightand hotel bookings or the part of a public administration application for schedulingannual earned income tax payments are examples of mashups.

—A workspace is a set of widgets that are likely to share data with each other inorder to complete a particular task. A web page that queries a particular agencyabout possible flights to a destination or visual spaces where personal and work-related particulars are entered to determine employee wage brackets are examplesof workspaces.

—A widget is a visual component composed of a user interface that provides simpleaccess to a backend resource or service. A map for searching a destination or aninterface for entering and storing personal and work-related particulars by invokinga remote public administration web service are examples of widgets. A widget hasthree elements: a visual interface, a set of data operators, and one or more backendresources that constitute the component’s business logic. Not all web EUD tools en-able end users to build new widgets from components. Some powerful tools like, forexample, OpenKapow, JackBe Presto Cloud or Yahoo! Dapper provide such capabil-ities. Otherwise, end users have to create widgets from the tool’s web programmingAPI (which is necessary in iGoogle, Yahoo! Pipes, or EzWeb, for example).

In short, as end users are unaware that they need a software development lifecycle,they rely on a framework, like FAST, to guide them step by step through the lifecycle andto exploit existing technology: visual web component catalogues, drag-and-drop-basedcomponent design and specification and catalogue-based search/recommendation.

On the other hand, our approach is based on a lifecycle with several product devel-opment phases. The framework should also guide users through each phase and pointout which requirements each phase should cover.

3.2. End-User Software Engineering Lifecycle Phases

Our iterative and incremental lifecycle is divided into a set of development phases.These phases are each composed of one or more end-user iterations through theseactivities. The framework will guide end users through decision making on when toundertake new iterations, which requirements to address in each phase, that is, end-of-phase milestones, and how much effort to put into each activity in each iteration.

The development phases are based on the unified process [Jacobson et al. 1999] andresearch by Murugesan et al. [2001]. They have been tailored to the particularities ofweb-centred EUSE.

—Inception. End users focus on identifying the problem and searching for coarse-grained components to tackle part of the target functionality. Users start to forman idea of what components they are going to need to solve their problem. The re-quirements and analysis activities account for most of the workload in this phase.Users are guided through the search for existing full solutions and their adapta-tion through parameterization to their particular problem. The FAST frameworkanalyses the requirements statement and locates different paragraphs that identifystandalone subproblems. Additionally, it analyses what parts of the statement (sen-tences and paragraphs) return a high number of recommendations of componentsthat are related to each other and independent of components that are recommendedby searches related to other sentences or paragraphs of the problem statement. Ituses this information to propose the division of the problem into subproblems, ad-vising end users to first tackle the paragraphs containing most keywords that havereturned satisfactory searches of off-the-shelf components.



—Elaboration. Users consider which mashup components they are going to need andhow to link them, creating a product baseline that can be expanded with other func-tionalities. They create a provisional structure for each mashup. This defines howmany workspaces they are to have, as well as a set of visual elements used to solvepart of the problem. In this phase, the analysis and design and implementation activ-ities account for most of the workload. The FAST framework retrieves the paragraphsof the statement not addressed before and advises users to start building prototypedesigns of these paragraphs. It guides users through the mashup components andexisting workspaces related to the target solution and helps them specify, but not yetdesign, the components that they are unable to find.

—Construction. End users address all the problem functionalities, starting with exist-ing prototypes and parts that have not yet been implemented but have been specifiedbased on their input and output data. To do this, they gradually build widgets intothe workspaces, linking components of any abstraction level with each other throughtheir input and output data. Users pay special attention to the use of backend re-sources and data operators, elements that define the internal widget behaviour. Thetesting stage accounts for most of the workload, because the previously specifiedparts are now fully implemented, and they need to be tested. FAST provides userswith guidance on how to run white-box tests to complete each part of the solution.FAST then takes users through the black-box testing of larger parts of the solution.

—Transition. The goal of this phase is to publish the resulting solution and componentsin collaborative catalogues in order to maximize their dissemination and encouragecooperation among users. In this phase, the deployment activity accounts for mostof the workload. FAST shows users how to share all the unpublished elements thatthey have used for later reuse.

4. EXPERIMENT: ANALYSIS AND DISCUSSION

We have presented an EUSE lifecycle with a framework that guides end users throughthe activities and phases of this software lifecycle. We now describe a case study ad-dressing the following research questions.

(1) RQ1. Do today’s web development environments enable users without program-ming skills to build a web solution for a particular problem that they are set?

(2) RQ2. Does the application of the presented framework-driven lifecycle (FAST) en-able users to build a web solution more successfully than before?

RQ1 and RQ2 were studied by asking 100 end users to develop a composite applica-tion to plan business trips. The end users were familiar with this task through theiroccupations and personal situations inside and outside the world of work. They wereasked to build a web application to search and book transport and hotels, and gathertourist information for destinations entered in a personal agenda. Annex A reports theproposed statement.

Figure 4 shows an example of one of the successful solutions developed by usersduring the experiment.

The requested application requires the use of from 22 to 24 components. Compo-nents include mashups, two workspaces implemented as two different tabs for man-aging dates and times (calendar workspace) and managing the actual trip (organizerworkspace), widgets, visual components, operators, backend services, etc. Componentassembly requires the creation of 20 dataflows among components. Users were givenaccess to components catalogues containing 650 components of different levels of ab-straction, making it hard for them to locate the right components, integrate thesecomponents properly (there are over 200 possible syntactically correct dataflows for



Fig. 4. Example of a final solution of the problem.

the 22 to 24 components) and assemble an error-free solution. For a full and detaileddescription of these components and dataflows and the development processes enactedby the sample of users using FAST guidance, see Lizcano [2012].

Table III characterizes the sample of 100 users and shows that none of the usershave programming skills, except for four who are knowledgeable about mashup tools(in this case iGoogle) and two with high-level Enterprise Service Bus (ESB) knowledge.An important step in this study was to validate the sample, statistically testing thatthe user characterization is not skewed. To do this, four qualitative variables associ-ated with each individual were created at the end of the RQ1 and RQ2 study. Theyhad Boolean variables, indicating whether or not subjects had been able to build asolution using each support tool offered for this study. An ANCOVA study, shown later(Table VIII), confirms that the variables are independent of the descriptive character-istics of the sample and that the quantitative and qualitative variables that describethe population are unbiased and correlate with the results of RQ1 and RQ2.

The tools available for carrying out this task for the RQ1 study were Yahoo! Pipes andDapper, OpenKapow and EzWeb tools, without guidance from the FAST framework. ForRQ2, EzWeb was used with the FAST framework to guide users through the presentedlifecycle. In any case, catalogues containing the same 650 components were assembledfor each tool. Users received basic training in each tool and tackled the given problemindividually. They were supervised by an author of this article throughout both the RQ1and RQ2 studies. The supervisor took notes on generally which steps users took in RQ2.



Table III. Sample Characterization

Characterization End users (100)GenderMale 52Female 48Age<20 years 1820–34 years 2435–49 years 2250–64 years 20>65 years 16Educational AttainmentSecondary School 24Vocational Training 26Bachelor’s Degree 24Master’s Degree 26EmploymentStudent 26Researcher 28Employee 46Experience and previous knowledgeMashup Platforms 4Web Services (SOAP, ESB, BPEL, etc.) 2HTML, CSS 0Java, J2EE 0JavaScript, AJAX 0Php, ASP 0OO Programming 0C, C++, C# 0Scripting, Perl 0Haskell, Prolog 0

4.1. RQ1. Development of the Problem using EUD Tools without a Web SoftwareDevelopment Lifecycle

Users received basic training in EUD and specifically web EUD. The training schedulewas as follows.

—Theory Session (4 Hours). Introduction and familiarization with widget and mashupdevelopment and intercommunication technology

—Practical Session (4 Hours). Solution development on the Yahoo! Dapper and Pipes,OpenKapow and EzWeb platforms

—Case Study (Variable). Hands-on laboratory experience of developing the proposedcomposite application on all three platforms

The Yahoo! and OpenKapow tools were selected for the study because of their pop-ularity and success [Lizcano et al. 2011a]. EzWeb was chosen as the third tool as it isan increasingly accepted open software tool for developing RIAs [EzWeb Project 2011].These tools were used without lifecycle support in this experiment.

Table IV shows the statistical data on how many users managed to build a validsolution that met all the set requirements and how long it took them to do so.

As Table IV shows, only five users managed to build a solution using Yahoo! Pipes,10 managed to build a solution with Open Kapow and 18 users managed build a solution



Table IV. Statistical Study in Response to RQ1

Development time (minutes)Satisfactory solutions achieved N Min. 1st Qu. Median Mean 3rd Qu. Max.Using Yahoo!Pipes and Yahoo! Dapper 5 100.00 150.00 200.00 182.00 220.00 240.00Using OpenKapow 10 15.00 71.25 165.00 137.00 197.50 230.00Using EzWeb 18 15.00 52.50 70.00 101.40 172.50 240.00

Table V. Number of Users that Were Successful using Tools

Succesful use of toolsNumber of users Yahoo! OpenKapow EzWeb

81 No No No9 No No Yes1 No Yes No4 No Yes Yes5 Yes Yes Yes

using EzWeb. These data suggest that the results achieved using all three tools arevery adverse. Looking at the users that built a satisfactory solution, we found that thefive Yahoo! Pipes users were also successful when they used Open Kapow and EzWeb.Nine out of the ten successful OpenKapow users also managed to solve the problemusing EzWeb. In conclusion, only 19 out of the 100 users managed to solve the problemusing at least one tool, as shown in Table V. And the mean time required to tackle theproblem was from one-and-a-half to three hours.

In response to hypothesis RQ1, we can say that the primary problem in the web EUDfield is not program quality or error proneness, but the fact that users are mostly unableto build a solution to a closed problem. The fact that 81% of users that had receivedtechnical training in the tool and composition mechanisms/languages were unableto compose a composite web application from the off-the-shelf components designed tosolve this problem reveals a clear epistemological problem: it is necessary to incorporatea lifecycle to support and guide users through this task.

After this experiment, the sample completed a survey containing open-ended qual-itative questions about the difficulties and obstacles that they had found using eachtool. The results are summarized here.

—Regarding the Yahoo! tools, 95% of the sample stated that they had no way of inter-connecting Yahoo! Dapper widgets with each other, 76% missed the option of beingable to compose widgets based on finer-grained components and 82% highlightedthat Yahoo! Pipes failed to provide useful wrapped services for end users.

—Regarding OpenKapow and RoboMaker (an additional tool supporting OpenKapow),over 90% of the sample found that component linking and tailoring mechanisms inKapow solutions were not handy (required programming knowledge), whereas only5% found the component search, location, parameterization and recommendationmechanisms to be satisfactory.

—Regarding the EzWeb tool, over 80% of the sample stated that users were unable toeffectively find the necessary widgets or build them from finer-grained elements.

In sum, users found it hard to locate and link widgets, which supports the ideathat a lifecycle is required.

4.2. RQ2. Software Development with a Framework Guiding End Users throughthe Software Lifecycle

As mentioned previously, FAST is a support tool to guide end users through the de-velopment of web applications following the presented lifecycle. FAST interacts with



Table VI. Statistical Study in Response to RQ2

Development time (minutes)Satisfactory solutions N Min. 1st Qu. Median Mean 3rd Qu. Max.Using EzWeb with FAST support 92 12.00 48.97 58.72 66.06 70.65 227.00

Table VII. Statistical Data about FAST Performance during the Experiment

FAST Performance Metrics (mean for 92 end users)Time per Time per Un-

Used Recommended Unused component Recommended Unused dataflow Debugged detectedcomponents components components recommendation dataflows dataflows recommendation errors errors22.30 31.20 8.90 0.02 msec 21.78 2.20 0.01 msec 15.45 0.02

other composite languages and platforms to support program development. FAST andEzWeb were used to tackle RQ2. To do this, FAST was integrated into the EzWeb visualenvironment. This was feasible because EzWeb is an open source tool and we were ableto modify its source code. Integration cost was minimal, as FAST acts like a plug-in orexternal component. It could be implemented in other tools relatively effortlessly butnot without access to their source code. We organized an experiment in which the sameusers were asked to tackle the same problem, but this time using the FAST frameworkto guide them through application development.

As the sample is exactly the same, no further studies, such as ANCOVA or post-hocTukey HSD-like tests, were necessary to check sample validity and homogeneity inorder to demonstrate the significance of results variance.

Table VI shows the statistical results for the number of successful users and devel-opment time.

We find that the use of a lifecycle as guidance results in an enormous increase (from18% to 92%) in the number of end users that complete the task successfully. We alsofind that development time drops, although this could be due to the fact that userswere familiar with the problem. This point is discussed later in the light of the resultsfor a problem that was new to our sample.

For the process enacted by users to find and correctly link the right components,search methods, recommendation success, etc., see Lizcano [2012]. A total of 78 out ofthe 92 users that solved the problem took the same steps, nine completed an additionaldevelopment iteration and another five did one less iteration than the others. (Thesewere the same five users that managed to solve the problem using all the tools proposedin the RQ1 study.) This report also specifies the components used by the 92 end usersthat managed to build a solution.

The eight users that failed all referred the same problem: they were unable to find thecomponents that they needed and promptly gave up, ignoring the guidance providedby the FAST framework.

Table VII shows statistical data evidencing FAST performance. It shows the numberof recommendations made by FAST, false positives (unused recommended components)and recommendation processing time, data linking errors not detected during testing,etc. for a catalogue containing 650 components.

We believe that the FAST recommendations, and the time taken to infer the recom-mendations from the components catalogue, the folksonomy created for the cataloguedcomponents and the ontology formalizing the data and concepts handled in the prob-lem domain, are efficient for a catalogue of 650 components because FAST efficientlyimplements an EUSE lifecycle.

Several additional studies were required to validate this research. We had to validatethe original sample studying its possible bias and the influence on conducted studies,check whether there was any correlation between user success or failure depending on



Table VIII. ANCOVA of RQ1 and RQ2 Results against Sample Characterization

Goodness of fit statisticsSum of

Observations weights Df R2 Adjusted R2 MSE MAPE DW Cp100 100 64 0.115 0.025 5.142 4.462 1.157 2

Analysis of varianceSource Df Sum of squares Mean squares F Pr> FModel 34 5.932 0.169 1.196 0.264Error 65 9.072 0.142

Corrected Total 99 15.004Computed against model = Mean(Y)

Type I sum of squares analysis:Source Df Sum of squares Mean squares F Pr> F

2.- Gender 1 0.042 0.042 0.294 0.5893.- Age 1 0.134 0.134 0.943 0.335

4.1- Education 3 0.752 0.251 0.968 0.3624.2-Employment 2 0.163 0.081 0.575 0.266

5.- Experience and 28 4.387 0.199 1.407 0.146previous knowledge

Type III sum of squares analysis:Source Df Sum of squares Mean squares F Pr> F

2.- Gender 1 0.524 0.175 1.232 0.3053.- Age 1 0.084 0.084 0.595 0.543

4.1- Education 3 0.212 0.106 0.949 0.3774.2-Employment 2 4.041 0.184 1.296 0.209

5.- Experience and previous 28 0.445 0.074 0.823 0.289knowledge

their characteristics, and check what bearing, if any, the fact that users were alreadyacquainted with the composition tool (EzWeb) and the set problem before they startedto use the FAST framework (thanks to RQ1) had. To validate the whole study, first wedevised qualitative variables that indicated whether or not the user had been successfulusing Yahoo!, Open Kapow, EzWeb, and EzWeb with FAST. These variables were usedto generate a single qualitative variable that had several dimensions and indicated thetools with which users had or had not been successful. Table VIII shows a covarianceregression study, ANCOVA, between the study variable (indicating which tools hadand had not been used successfully) and the qualitative and quantitative variablesdescribing each user.

Analysing Table VIII, we find that the coefficient of determination R2 is very low(0.115). This suggests that there is a high percentage of variability in the modelledmean variable so that gender, age, educational attainment, employment and previousexperience (the quantitative and qualitative variables for each individual) appearto explain only 11.5% of RQ1 and RQ2 results. The other values are due to otherunknown variables. This value of R2 and adjusted R2 suggests that the resultsobtained by end users are largely (88.5%) independent of the user characteristics. Themodel error values, MSE (mean squared error) and MAPE (mean absolute percentageerror) are very high (well above the ideal value 0), again suggesting that the modeldoes not precisely explain the behaviour of the variable under study in the sample.Additionally, DW (Durbin-Watson statistic) values are not close to 0. This implies thatthere is no autocorrelation among the qualitative variables, without which the studywould not be valid. Finally, Cp (Mallows’ Cp statistic) suggests that the model is ableto exactly explain the results of only two of the 100 individuals. We have conducted



Table IX. Additional Study of RQ2 against RQ1 Dividing the Sample to Refute ExperimentalBias

Development time (minutes)Satisfactory solutions N Min. 1st Qu. Median Mean 3rd Qu. Max.Group A 9 15.00 53.29 68.00 99.71 170.50 228.00Group B 47 16.00 50.81 57.62 59.60 72.57 230.00

a Type I and Type III sum of squares analysis. Type I (sequential) analysis providesan incremental improvement in the sum of squared errors as each effect is added tothe model, and Type III (orthogonal) analysis is able to reduce the sum of squarederrors by adding the term after all other terms have been added to the model. Theircombined use means that we do not have to be concerned about the order in which thefactors were added to the regression model. Taken together, the model results validatethe sample, indicating that there is no bias related to the qualitative and quantitativevariables characterizing the users and their recruitment for the study.

Looking at the Pr>F values of the ANCOVA model, we find that the characteristicthat is most related to the user being successful or failing to develop a solution is age(the greatest Pr>F in the study, equal to 0.543). We examined user age and found nostatistical evidence of a direct correlation between age and the results of RQ1 and RQ2,as Pr>F is still less than 1. However, the outliers in both studies, that is, users thatwere successful without FAST (19%) and users that failed using FAST (8%) includeseveral young users (aged from 20 to 30 years) in the first case and several older users(aged over 55 years) in the second. In any case, the correlation between age and theresult is very small, and many people within these age groups achieved completelydifferent results. Additionally, the sample is balanced with respect to age, with anequivalent percentage of individuals in each age group.

Further validation is required to check whether the order in which RQ1 and RQ2were investigated affects the results: users were already familiar with the visual tool(EzWeb) and the problem in the RQ2 experiment and they might have achieved betterresults than if they had first encountered them in the RQ2 study. Tackling RQ2 firstwould definitely have altered the results for RQ1, as it is easy for users followinga lifecycle to memorize which components they needed, how they were linked andhow they solved the problem. To overcome this obstacle, we used a second, completelydifferent but equally complex statement. This new statement is based on building aweb application that checks the content of a web site at regular intervals and notifiesany change via email or SMS. Annex B reports the problem statement, and the off-the-shelf components available in the EUD tools used in the study were sufficient forsolving the problem. We had the same 650 components, and the problem required theuse of some 20-22 components and another 20 dataflows.

We divided the sample of 100 users into two independent and separate groups, A andB, so that group A went about solving the problem using EzWeb without FAST andgroup B tried to solve it using FAST and EzWeb. Groups A and B were each formedby 50 selected users that were not biased by age, gender, education, employment orprevious experience. The grouping specifically accounted for outlier users identified inearlier studies: the 19 users who successfully solved the problem without FAST wereproportionately divided across the two groups (10 in A and nine in B) and the eightthat failed to build a solution using FAST were split equally (four per group). A and Bwere unbiased and equivalent groups in terms of expected results. Both groups werefamiliar with EzWeb from the last experiment designed in response to RQ1. The resultsfor each group are shown in Table IX.

Note again that users that used EzWeb without FAST tend to fail (despite beingfamiliar with the tool) so that only nine out of 50 users managed to achieve satisfactory



results. On the contrary, there was widespread success among the group of users thatused FAST (even though they were unfamiliar with the problem). Only three out of 50users were unsuccessful.

A linear correlation study of the qualitative variable measuring whether users weresuccessful/unsuccessful with and without FAST in the first experiment returns a valuecor = 0.95254468 (close to 1). This value is very similar to the result of the secondexperiment, where cor’ = 0.83710170. The correlations, which are very alike and closeto 1, suggest that the result of the RQ2 study is equivalent to what users would haveachieved if they had not previously developed the solution to the problem stated inRQ1. Non-parametric Wilcoxon-type correlation tests are unnecessary in view of thehigh linear correlation values.

In conclusion, the data gathered for 50 users that used FAST without previousknowledge of the problem was equivalent to when the sample of 100 users used FASTwith a known problem.

There are two key aspects of the validated study that require investigation: productquality and development time.

It is important to study whether the use of FAST outputs a quality and error-freeproduct, which is an EUSE goal. The case study reviewers found that the createdcomposite applications worked efficiently and were useful as opposed to the solutionsdeveloped to solve the problem stated in RQ1 [Hoyer et al. 2011]. They used white-boxtests to inspect the source code and the low-level components developed in each ap-plication. The applications met the set requirements and had similar computationalefficiency, response times and robustness to the applications built by the reviewers tosolve the set problem using composite development tools (like OpenKapow or EzWebwithout FAST support). In some cases, the applications had dataflows that users hadadded (with framework guidance in all cases) to solve aspects that were not specifiedin the statement or were optional. Such flows led to longer response times, but notto problems of robustness. These positive results are partly attributable to the com-ponents used in the end-user compositional model developed using web development,testing and maintenance technologies [Gaedke 2008]. Hoyer et al. [2011] conductedan independent study as part of the FAST project and found that the 92 applicationsbuilt for the problem met the specified requirements correctly, robustly and reliably,whereas 19 applications built in the study of RQ1 had some operational errors andmalfunctions. This result suggests that the presented lifecycle not only enables usersto build a solution (which is demonstrated in the RQ2 study) but also manages to elim-inate possible operational errors in the resulting application (which has been verifiedby independent researchers [Hoyer et al. 2011]).

With respect to development time, it is worthwhile examining whether the usersthat managed to solve the problem took on average longer to develop a solution withoutthan with the support framework. In principle, the time taken using FAST could beconsidered to be dependent on the fact that users were already familiar with theproblem, but this hypothesis has been rejected as a result of the RQ2 study. Figure 5shows boxplots illustrating the development times taken in each case. The values havebeen extracted from the experiment results.

Very few data are available for the first three tools, as only 5, 10 and 18 usersmanaged to satisfactorily develop a solution. Statistical studies to fit specific proba-bility distributions are out of the question with such a small sample size. However,the box plots suggest that the use of FAST does appear to reduce development timecompared with Yahoo! Pipes and Dapper and OpenKapow, whereas no relevant sta-tistical difference can be inferred with respect to EzWeb, as both boxes overlap in thechart. Additionally, there are outlier values in FAST that are closer to the developmenttime results for the first two tools. This appears to suggest that the use of FAST does



Fig. 5. Development times in each case.

not have a relevant statistical impact on solution development time, as this appearsto depend directly and exclusively on the tool used. FAST does, however, manage tobring development times towards a similar value for almost all the sample, reducingdevelopment time variance. With respect to the results achieved in each tool, Yahoo!Pipes and Dapper is the tool that took most development time, around 200 minutes,followed by OpenKapow that took 160 minutes, and EzWeb with 75 minutes. As theboxes overlap, we can infer that there are not enough data to claim that any of thethree is able to reduce development time significantly. The FAST/EzWeb combinationdoes, however, appear to reduce development times compared with OpenKapow, and,more significantly, with respect to Yahoo! tools.

Figure 6 gives a rough overview of the division of the workload governing the lifecy-cle. The measurements correspond to the mean time, in minutes, spent by experimentusers on each activity and phase after adding up the measurements taken for the twostated problems. The total mean time spent on solving the problems was 63 minutes.We find that most of the workload is spent on requirements and analysis in the firstand second iterations of the inception phase, respectively. In the elaboration phase,the workload initially targets analysis and later shifts to design and implementation.The workload focuses on the design and implementation activities, whereas a lotof time is spent on testing and dataflow creation in the construction phase. Finally,the transition phase focuses on the sharing and deployment activity. This workloaddivision is comparable to traditional SE cycles, such as RUP, which obliges end usersto properly organize their problem-solving workload, which they would be unable to dowithout guidance. These data are evidently problem dependent, and the lifecycle wouldhave to be applied to several problems and domains to be able to precisely specify thetime spent on each activity and phase. As a result, it would be possible to schedule thedevelopment workload of different application types and characterize the lifecycle.

5. SUPPORT TOOLS FOR A SOFTWARE ENGINEERING LIFECYCLE FOR THE WEB

The WEUSE lifecycle requires proper support tools for enactment. The first require-ment is a components model to define a compositional architecture to enable endusers to develop their applications from existing web components. The second is a



Fig. 6. Division of the mean workload for each activity and phase in each lifecycle iteration, with the meantime (minutes).

FAST-like wizard, which, based on the above components model, guides end usersthrough applications development. There follows a description of these support tools.

5.1. Components Model

The components of the components model of the framework that guides end usersthrough the software lifecycle (FAST) have to conform to a set of premises. Most oftoday’s web components focusing for EUD already comply with these premises [Lizcanoet al. 2011b].

—They should have a user-comprehensible description of component function and pos-sible applications. This should be a social and collaborative description so that allusers can actively participate in component definition, development and mainte-nance. Additionally, components should be able to be tagged with simple words in or-der to set up component folksonomies (socially elaborated tagging-based taxonomies)for later keyword-based searches and recommendations.

—Each component should have an abstract implementation and offer a particularfunction that applies input data, originating output data or some sort of visualinformation.

—Components should have a visual user-parameterizable interface.—Components should have different levels of abstraction. The more general compo-

nents target users without programming skills, whereas more specific componentstarget users with some composite development experience. Current component de-velopment tools tackle this feature differently [Lizcano et al. 2011a].

—There should be a dataflow mechanism for interrelating components at the samelevel of abstraction, leading to higher-level components.



Fig. 7. UML2 model for web-centred EUSE components.

—Data with a particular flow should have an associated meaning, for example, throughlinks with problem domain ontology concepts, which would be useful for advisingusers about which elements to link.

—Off-the-shelf components should be compiled in a federated catalogue, publishingcomponents from software suppliers or other users. These catalogues should be or-ganized by levels depending on how abstract components are. These catalogues havereceived considerable backing in several EUD fields with very good results [McDanieland Myers 1999; Toomim et al. 2009]. To improve efficiency, Gulley [2006] proposesusing element and supplier rankings, natural language comments and tags.

Figure 7 is an UML2 modelling language diagram illustrating the components modelused by the FAST framework to drive the end-user web SE lifecycle.

The components in Figure 7 meet the above requirements [Lizcano et al. 2011b;Obrenovic and Gasevic 2009]. Clearly, each component can be subdivided into finer-grained components linked by user-defined dataflows. The component hierarchy rangesfrom full solutions to visual elements, data operators and backend resources. Eachcomponent, described in natural language, provides an interface and enables access toa set of web resources. FAST manages a specification of each component according toits input and output data and a set of tags and use examples indicating the meaning ofeach component and the purposes for which other users have used the component andhow. Inputs and outputs are termed pre- and postconditions in FAST, as a component isspecified by logical rules, and the validity of the dataflows is evaluated by means of aninference engine that manages these rules. The rules use facts, which are statementsabout the component data syntax and semantics. This is the particular approach takenby FAST but is not necessarily the only valid solution for supporting web EUSE.

5.2. Implementation Details of FAST

The FAST framework is a prototype intelligent wizard that guides end users throughthe SE lifecycle programmed in its workflow and checks whether user actions conformto the lifecycle. Figure 8 shows the algorithm governing the internal operation of FAST.



Fig. 8. Diagram of activities that govern FAST behaviour.

The algorithm input is a natural language text written by end users describing thetarget solution. FAST applies natural language processing techniques, presented inZhou and Zhang [2003], called NLPIR (natural language processing for informationretrieval). NLPIR divides the problem into several lifecycle iterations and recommendsparticular components for tackling each iteration. For recommendation purposes, FASTrequires catalogue components to be endowed with semantics. In the application ex-ample, FAST interacts with EzWeb, whose catalogue contains 650 components. Thesecomponents can have different levels of abstraction so that less detailed componentsare elaborated from more detailed, atomic components, which are developed and pub-lished by software developers and providers. These developers describe such compo-nents using: (a) natural language descriptions, which are useful for users to analysethe recommendations made by FAST, (b) descriptive labels that enable FAST to build acomponents folksonomy, based on lightweight semantics, which are useful for buildingsocial classifications similar to web portals like del.icio.us, and (c) input and outputdata semantics, which is specified by an ontology of domain-specific concepts.

The most complex task is to endow the input and output data with semantics. Thissemantics is based on an ontology created by a domain expert and annotations madeby the atomic component software developers. The other annotations are made byproviders but can be improved and enriched by end users. When components are builtfrom other more detailed components, they inherit the semantic annotations of the data



that they handle so that end users can build new more abstract components withouthaving to be familiar with the conceptual ontology of the problem domain.

When users describe their solution, FAST extracts keywords which it uses to searchthe folksonomy of the above components using NLPIR. It uses the results to debugthe recommendations based on the data already built into the design, prioritizingcomponents using similar data. To do this, FAST reasons using the conceptual ontologyassigning the semantics to the employed data.

After recommending components to end users, FAST specifies which dataflows canbe established among existing components. To do this, it reasons again on the eachcomponent’s input and output data, advising end users to link components with datathat have been linked by other users, link data with equivalent semantics (reasoningon the problem domain conceptual ontology) and finally linking data with the samesyntax (data types).

After establishing a dataflow, FAST guides users through the dataflow validationtest prompting end users to enter standard problem domain input data. To do this,FAST draws on the ontology that provides the data semantics used in the design. Thisontology stores both standard data and outlier data for each concept to be handled,which information is used to guide testing.

Finally, FAST helps end users to publish their partial solution and search finer-grained elements if the target functionality has not yet been implemented. This leadsto a new iteration of the lifecycle. To do this, FAST uses a publication wizard anditerates the above algorithm. For an example of FAST operation, see Lizcano [2012].

Note that FAST is an intelligent framework that is able to enrich the semantics of thecomponents catalogued for future software lifecycles. If end users develop successful ap-plications, FAST establishes relationships among the successfully linked componentsand creates subassemblies of related components based on use by the end-user com-munity. These relationships are created by means of new lightweight labels as if theywere user labels to ensure that the folksonomy structure is unchanged. This machinelearning is vital for limiting the number of false positives that would be produced whenthe size of the catalogue is over a thousand components.

6. CONCLUSIONS AND FUTURE LINES

This article presents two main contributions. First, it notes that the primary weaknessof WEUSE is not the tools, visual languages or development techniques, but theabsence of a software lifecycle supported by a framework to guide users through allthe development activities and phases. End users without basic software developmentknowledge do not address the entire development process and have need of support,especially in the requirements, analysis and design/implementation activities, to tellthem what they have to do and how to do it. A software development assistant isobviously useful for users without programming skills, but this paper evidences thatusers are generally unable to develop applications without such an assistant. Second,this article puts forward a WEUSE lifecycle and presents a support framework that hasbeen demonstrated to be valid. The reported experiment shows that the better resultsin response to RQ2 can be attributed to the inclusion of a software lifecycle tailored forend users and support software to guide users through the lifecycle, which is what dis-tinguishes the RQ1 and RQ2 studies. This was confirmed when the sample was dividedinto two groups that were familiar with the tool and they were set a new problem: thegroup that did not use the framework failed again, whereas the group that did use theframework was just as successful as when they were acquainted with the problem.

The results in the field of web-centred EUSE are promising. Proof of this is that thelifecycle is being used in the Spanish public administrations to promote digital spacesof interaction with citizens using EUD technologies. A portal has been set up which



Saragossa citizens and visitors can use to build their own composite web application toorganize their leisure activities in the city and book hotel rooms, museum tickets, puttogether their personal tourist guide, book entertainment, etc. [Tejo-Alonso et al. 2010].There is a catalogue of components for locating addresses on the city map, and accessingtourist, historical, hotel and restaurant information. This portal has about 500 com-ponents, over half a million total visits and composite web applications and receivesabout 100 visits per day. There are no exhaustive quantitative studies, but qualitativesurveys suggest that acceptance by citizens is very satisfactory [Lizcano et al. 2011a].

On the other hand, Andalusia’s Regional Government [2011] has set up a portalthat enables public administration users to use EzWeb and FAST to build their ownweb application to manage bureaucratic formalities. It has about 600 components andany citizen is able to build a web application from which to centralize all their publicadministration formalities, such as the tax payments, city or intercity road trafficinformation, fine and traffic management, and official document, census, employmentrecord management, etc. With about 50 visits per day, it has also been well received bycitizens who have built over two thousand web applications [Lizcano et al. 2011b].

Additionally, we are using and testing the presented software development lifecycleand its associated framework as part of two on-going FP7 research projects: 4CaaSt[4CaaSt Project 2012] (Building the Platform-as-a-Service of the Future) in the contextof its Mashup-as-a-Service solution, and FI-WARE [FI-WARE Project 2012] (FutureInternet Core Platform) in the context of its applications and services ecosystem andgeneric delivery framework enablers for end users to build application mashups. So weexpect to conduct further experiments as part of these projects in order to update andrefine our approach. The use of FAST as part of the technology foundation (FI-WARE)in the context of the European public-private partnership on the Internet of the Future[FI-PPP 2012] extends the lifecycle to R&D projects covering areas as far apart asthe transportation of goods and people, energy efficiency or bank management in theframework of smart cities.

The main line of future research is to study the feasibility of a framework-supportedlifecycle (be it FAST or another) for other end-user approaches (apart from RIAs andweb-based composite applications) and apply the lifecycle to other fields such as spread-sheets, mail filtering, WYSIWIG web contents development applications, etc. to enableusers to build nontrivial, quality and error-free solutions.

Other future lines of work are: (a) study alternative forms of guiding end usersthrough the proposed lifecycle, such as peer support, online help, etc. that direct theuser through a SE methodology; (b) test FAST performance in composite web design en-vironments with a very high number of components, which is not feasible to date as allweb EUD tools have fewer than one thousand components; (c) formalize a componentsmodel establishing some clear standardization criteria on end-user web componentsfor that will improve the application of WEUSE. This formalization would be the firststep towards the export of web development tool components to other tools, using acommon standard. This would increase the number of available components with aview to tackling a general-purpose end-user software lifecycle.

APPENDIXES

A. STATEMENT OF PROBLEM 1 IN STUDY RQ1 AND RQ2

In RQ1 and RQ2, end users tackled the development of a web application in responseto the following problem.

As part of a R&D project in which he is participating, a higher education worker hasto make numerous national and international trips. The project has several partnersof different types and origins.



The R&D project has a web-based general agenda shared by all the project partners.All face-to-face meetings are posted in this agenda, specifying the meeting date andtime, venue and agenda. The higher education institution employing the user activelycooperates with two travel agencies, one specialized in high-speed trains and the otherin long-distance flights, and both manage all the travel and accommodation options atthe full range of hotels.

(1) The user consults the shared R&D project agenda every day to check whether thereis a new meeting that he should attend.

(2) If there is to be meeting, he has to check his personal agenda to find out whetherhe can attend the meeting and fill in the details of the new meeting, the meetingagenda, etc.

(3) The user looks up the meeting venue, and searches for it on a map. Then, heaccesses the travel agency services and checks what travel options they offer, aswell as price. Normally, he compares the two options and chooses one agency or theother depending on the travel options, length of stay and price.

(4) If the trip is to last longer than a day, the user searches hotels near to the meetingvenue and checks the prices per room and night offered by the travel agencies.

(5) The department employing the user has a spreadsheet-based software programthat manages the department-run R&D project budget. It contains spreadsheetsthat can be used to check the travel budget currently available for each project andmanage new expenses. It is the user’s job to calculate how much the travel andchosen accommodation will cost, add this up and check that there is enough moneyavailable for the trip and deduct it from the project budget.

(6) Then, the user makes the bookings one by one.(7) Finally, the user checks the Internet for information about his destination, demo-

graphic characteristics, weather forecast, etc.

The user has many software solutions to tackle this repetitive task (project agenda,personal agenda, travel agency services, department cash flow program, etc.) but hasto access distributed information, heterogeneous services, etc., separately.

B. STATEMENT OF PROBLEM 2 IN STUDY RQ2

Part of a user’s routine work is to supervise changes and notifications published by twoof his country’s public administration web pages. This user wants to build an applica-tion that is capable of automatically reviewing these two web pages and emailing andSMS messaging these specific changes to him. Therefore he is looking for an applicationthat:

(1) Stores a baseline containing the original status of the two webpages.(2) The webpages do not publish RSS or notify content changes in any other way. The

application should examine these web pages at a user-configurable time intervaland check whether any changes have been made compared against the baseline.

(3) The application will SMS message or email an outline of any changes made to theuser’s mobile phone and email address. Both data should obviously be configurableat runtime.

ACKNOWLEDGMENTS

The authors would like to thank the 100 end users of the experiment for their interest, participation andtime.

REFERENCES

4CAAST PROJECT. 2012. Official web site. http://4caast.morfeo-project.org.AMICO. 2012. AMICO web platform. http://amico.sourceforge.net.



ANDALUSIA’S REGIONAL GOVERNMENT. 2011. Official web site. http://www.juntadeandalucia.es/index.html.BECK, K. 2000. Extreme Programming Explained: Embrace Change. Addison-Wesley Longman Publishing

Co., Inc. Boston, MA.BLACKWELL, A. F. 2002. First steps in programming: A rationale for attention investment models. In Proceed-

ings of the IEEE Symposia on Human-Centric Computing Languages and Environments.BOLIN, M., WEBBER, M., RHA, P., WILSON, T., AND MILLER, R. 2005. Automation and customization of ren-

dered web pages. In Proceedings of the ACM Symposium on User Interface Software and Technology.163–172.

BRANDT, J., GUO, P., LEWENSTEIN, J., AND KLEMMER, S. R. 2008. Opportunistic programming: How rapid ideationand prototyping occur in practice. In Proceedings of the Workshop on End-User Software Engineering(WEUSE).

BURNETT, M., COOK, C., AND ROTHERMEL, G. 2004. End-user software engineering. Comm. ACM, 47, 9, 53–58.BURNETT, M., COOK, C., PENDSE, O., ROTHERMEL, G., SUMMET, J., AND WALLACE, C. 2003. End-user software

engineering with assertions in the spreadsheet paradigm. In Proceedings of the 25th InternationalConference on Software Engineering. IEEE Computer Society, pp. 93–103.

BURNETT, M., SHERETOV, A., REN, B., AND ROTHERMEL, G. 2002. Testing homogeneous spreadsheet grids withthe “What You See Is What You Test” methodology. IEEE Trans. Softw. Eng. 28, 6, 576–594.

CHAMBERS, C. AND ERWIG, M. 2009. Automatic detection of dimension errors in spreadsheets. J. Vis. Lang.Comput. 20, 4, 2009.

CLERMONT, M. 2003. Analyzing large spreadsheetprograms.In Proceedings of the 10th Working Conference onReverse Engineering. 306–315.

COSTABILE, M. F., FOGLI, D., MUSSIO, P., AND PICCINNO, A. 2006. End-user development: The software shapingworkshop approach. In End User Development, H. Lieberman, F. Paterno, and V. Wulf, Eds., Springer,183–205.

DAVIS, J. S. 1996. Tools for spreadsheet auditing. Int. J. Hum.-Comput. Stud. 45, 429–442.DIETHELM, I., GEIGER, L., ZUNDORF, A. 2005. Applying story driven modeling to the Paderborn shuttle system

case study. In Scenarios: Models, Transformations and Tools, S. Leue and T. J. Systa, Eds., Lecture Notesin Computer Science, vol. 3466, Springer, Berlin, 109–133.

DITTRICH, Y., LINDEBERG, O., AND LUNDBERG, L. 2006. End-user development as adaptive maintenance. In EndUser Development, H. Lieberman, F. Paterno, and V. Wulf, Eds., Springer, 295–313.

EZWEB. 2012. EzWeb web platform. http://ezweb.morfeo-project.org/.EZWEB PROJECT. 2011. Official demo web site. http://demo.ezweb.morfeo-project.org.FAST PROJECT. 2011. Official demo web site. http://demo.fast.morfeo-project.org.FISCHER, G. AND GIACCARDI, E. 2006. Meta-design: A framework for the future of end user development. In End

User Development Empowering People to Flexibly Employ Advanced Information and CommunicationTechnology, H. Lieberman, F. Paterno, and V. Wulf, Eds., Kluwer Academic Publishers, 427–457.

FI-WARE PROJECT. 2012. Official web site. http://www.fi-ware.eu.FI-WARE PPP OFFICE. 2012. Official web site. http://www.future-internet.eu/home/future-internet-ppp.html.GAEDKE, M. 2008. Web engineering: Creating solutions in the age of emotion, SOA, and Web 2.0. In Proceed-

ings of the 17th International World Wide Web Conference, (Tutorial).GALLETTA, D. F., HARTZEL, K. S., JOHNSON, S. E., JOSEPH, J. L., AND RUSTAGI, S. 1996. Spreadsheet presentation

and error detection: An experimental study. J. Manage. Inf. Syst. (Special issue: Information technologyand its organizational impact) 13, 3, 45–63.

GHEZZI, C., JAZAYERI, M., AND MANDRIOLI, D. 2002. Fundamentals of Software Engineering. Prentice-Hall.GOOGLE. 2012. iGoogle web platform. http://www.google.com/ig.GREEN, T. R. G., BLANDFORD, A., CHURCH, L., ROAST, C., AND CLARKE, S. 2006. Cognitive Dimensions: Achieve-

ments, new directions, and open questions. J. Vis. Lang. Comput. 17, 4, 328–365.GULLEY, N. 2006. Improving the quality of contributed software on the MATLAB file exchange. In Proceedings

of the 2nd Workshop on End-User Software Engineering, in Conjunction with the ACM Conference onHuman Factors in Computing.

HEINEMAN, G. T. AND COUNCILL W. T. 2001. Component-based software engineering: Putting the pieces together.ACM Press.

HENDERSON, A. AND KYNG, M. 1991. There’s no place like home: Continuing design in use. In Design At Work,J. Greenbaum and M. Kyng, Eds., Hillsdale, N. J. Lawrence Erlbaum Associates, Publishers, 219–240.

HOLZINGER, A. 2005. Usability engineering methods for software developers. Comm. ACM 48, 1, 71–74.HOYER, V., FUCHSLOCH, A., KRAMER, S., MOLLER, K., AND LOPEZ, J. 2010. Evaluation of the FAST imple-

mentation. Tech. rep. D6.4.1, FAST Consortium. https://files.morfeo-project.org/fast/public/M24/D6.4.1ScenarioEvaluation M24 Final.pdf.



IGARASHI, T., MACKINLAY, J. D., CHANG, B.-W., AND ZELLWEGER, P. T. 1998. Fluid visualization of spreadsheetstructures. In Proceedings of the IEEE Symposium on Visual Languages, pp. 118–125.

JACKBE. 2012. JackBe Presto Cloud web platform. http://prestocloud.jackbe.com/.JACOBSON, I., BOOCH, G., AND RUMBAUGH, J. 1999. The Unified Modeling Language User Guide. Addison Wesley

Longman Publishing Co., Inc., Redwood City, CA,JANNER, T., SIEBECK, R., SCHROTH, C., AND HOYER, V. 2009. Patterns for enterprise mashups in B2B collabo-

rations to foster lightweight composition and end user development. In Proceedings of the IEEE 7thInternational Conference on Web Services, pp. 976–983.

KAPOW SOFTWARE. 2012. OpenKapow and Kapow Katalyst web platform. www.kapowsoftware.com.KAY, A. C. 1977. Microelectronics and the personal computer. Scientific Amer. 231–244.KELLEHER, C. AND PAUSCH, R. 2005. Lowering the barriers to programming: A taxonomy of programming

environments and languages for novice programmers. J. ACM Comput. Surv. 37, 2, 83–137.KO, A. J. AND MYERS, B. A. 2004. Designing the Whyline: A debugging interface for asking questions about

program failures. In Proceedings of the ACM Conference on Human Factors in Computing Systems, pp.151–158

KO, A. J., ABRAHAM, R., BECKWITH, L., BLACKWELL, A., BURNETT, M., ERWIG, M., SCAFFIDI, C., LAWRANCE, J.,LIEBERMAN, H., MYERS, B., ROSSON, M. B., ROTHERMEL, G., SHAW, M., AND WIEDENBECK, S. 2011. The state ofthe art in end-user software engineering. J. ACM Comput. Surv. 43, 3, Article 21.

KO, A. J., ABRAHAM, R., BURNETT, M., AND MYERS, B. A. 2009. Guest Editors’ Introduction: End-User SoftwareEngineering. IEEE Softw. 26, 5, 16–17.

LIEBERMAN, H., PATERNO, F., AND WULF, V. 2006. End-User Development. Kluwer/Springer Academic Publishers,Dordrecht, The Netherlands.

LIN, J. AND LANDAY, J. A. 2008. Employing patterns and layers for early-stage design and prototyping of crossdevice user interfaces. In Proceedings of the ACM Conference on Human Factors in Computing Systems,1313–1322.

LITTLE, G., LAU, T. A., CYPHER, A., LIN, J., HABER, E. M., AND KANDOGAN, E. 2007. Koala: Capture, share,automate, personalize business processes on the web. In Proceedings of the ACM Conference on HumanFactors in Computing Systems (CHI ’07). 943–946.

LIZCANO, D. 2012. Description of the development process enacted by surveyed users. Tech. rep. http://apolo.ls.fi.upm.es/eud/solution development method.pdf.

LIZCANO, D., ALONSO, F., SORIANO, J., AND LOPEZ, G. 2011a. A new end-user composition model to empowerknowledge workers to develop rich internet applications. J. Web Eng. 3, 10, 197–233.

LIZCANO, D., ALONSO, F., SORIANO, J., AND LOPEZ, G. 2011b. End-user development success factors and their ap-plication to composite web development environments. In Proceedings of the 6th International Conferenceon Systems, (ICONS ’11), 99–108.

MACIAS, J. A. AND PATERNO, F. 2008. Customization of web applications through an intelligent environmentexploiting logical interface descriptions. Interact. Comput. 20, 1, 29–47.

MACKAY, W. E. 1990. Patterns of sharing customizable software. In Proceedings of the ACM Conference onComputer-Supported Cooperative Work. 209–221.

MARMITE. 2012. Marmite web platform. http://www.cs.cmu.edu/∼jasonh/projects/marmite/.MCDANIEL, R. AND MYERS, B. 1999. Getting more out of programming-by-demonstration. In Proceedings of the

ACM Conference on Human Factors in Computing Systems. 442–449.MCILROY, M. D. 1968. Mass produced software components. Software Engineering—NATO Science Committee

Report. P. Naur and B. Randell, Eds., 138–155.MICROSOFT. 2012. Microsoft Popfly web platform. http://www.popfly.com.MØRCH, A. AND MEHANDJIEV, N. D. 2000. Tailoring as collaboration: The mediating role of multiple represen-

tations and application units. Comput. Support. Cooperative Work 9, 1, 75–100.MØRCH, A. I., STEVENS, G., WON, M., KLANN, M., DITTRICH, Y., AND WULF, V. 2004. Component-based technologies

for end-user development. Commu. ACM 47, 9. 59–62.MURUGESAN, S., DESHPANDE, Y., HANSEN, S., GINIGE, A., AND MURUGESAN, S. 2001. Web engineering: A new

discipline for development of web-based systems web engineering. Lecture Notes in Computer Science,Eds., Springer Berlin.

MYERS, B. A., BURNETT, M., ROSSON, M. B., KO, A. J., AND BLACKWELL, A. 2008. End user software engineering.In Proceedings of CHI Special Interest Group Meeting and in Extended Abstracts on Human Factors inComputing Systems, ACM, New York, 2371–2374.

NARDI, B. A. 1993. A Small Matter of Programming - Perspectives on End User Programming. The MIT Press,Cambridge, MA.



NETVIBES. 2012. Netvibes web platform, 2012. http://www.netvibes.com.NEWMAN, M. W., LIN, J., HONG, J. I., AND LANDAY, J. A. 2003. DENIM: An informal web site design tool inspired

by observations of practice. Human-Comput. Interact. 18, 3, 259–324NICHOLS, J. AND LAU, T. 2008. Mobilization by demonstration: Using traces to re-author existing web sites. In

Proceedings of the 13th Symposium on Intelligent User Interfaces, 149–158.NING, J. Q. 1997. Component-based software engineering (CBSE). In Proceedings of the 5th International

Symposium on Assessment of Software Tools and Technologies, 34–42.OBRENOVIC, Z. AND GASEVIC, D. 2009. Mashing up oil and water: Combining heterogeneous services for diverse

users. IEEE Internet Comput. 13, 6, 56–64.OSTROWSKI, K. AND BIRMAN, K. 2010. Storing and accessing live mashup content in the cloud. In Proceedings

of the 3rd ACM International Workshop on Large Scale Distributed Systems and Middleware, 7–11.PANKO, R. 1995. Finding spreadsheet errors: Most spreadsheet models have design flaws that may lead to

long-term miscalculation. Information Week, (5/95), 100.PROGRAMMABLE WEB. 2012. Programmable Web social portal. http://www.programmableweb.com.RODE, J., BHARDWAJ, Y., PEREZ-QUINONES, M. A., ROSSON, M. B., AND HOWARTH, J. 2005. As easy as “Click”:

End-user web engineering. In Proceedings of the International Conference on Web Engineering. 478–488.ROSSON, M. B., BALLIN, J., AND RODE, J. 2005. Who, what, and how: A survey of informal and professional web

developers. In Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing,199–206.

ROTHERMEL, G., BURNETT, M., LI, L., DUPUIS, C., AND SHERETOV, A. 2001. A methodology for testing spreadsheets.J. ACM Trans. Softw. Eng. Methodol. 10, 1, 110–147.

SCAFFIDI, C., SHAW, M., AND MYERS, B. 2005. The “55M End User Programmers” estimate revisited. Tech. rep.CMU-ISRI-05-100, Carnegie Mellon University.

SEGAL, J. 2007. Some problems of professional end user developers. In Proceedings of the IEEE Symposiumon Visual Languages and Human-Centric Computing, 111–118.

STIEMERLING, O. 2000. Component-based tailorability. Ph.D. thesis (unpublished). University of Bonn,Germany.

STIEMERLING, O. AND CREMERS, A. B. 2000. The evolve project: Component-based tailorability for CSCW appli-cations. Artif. Intell. Soci. J. 14, 120–141.

SUTCLIFFE, A. AND MEHANDJIEV, N. 2004. End-user development: tools that empower users to create their ownsoftware solutions. Comm. ACM 47, 9, 31–32.

SZYPERSKI, C. 1998. Component Software – Beyond object-oriented programming. Addison-Wesley, Reading,MA.

TEJO-ALONSO, C., FERNANDEZ, S., BERRUETA, D., POLO, L., FERNANDEZ, M. J., AND MORLAN, V. 2010. EZaragoza, atourist promotional mashup. Tech. rep. http://idi.fundacionctic.org/eZaragoza/ezaragoza.pdf.

TOOMIM, M., DRUCKER, S. M., DONTCHEVA, M., RAHIMI, A., THOMSON, B., AND LANDAY, J. A. 2009. Attaching UIenhancements to websites with end users. In Proceedings of the 27th ACM Conference on Human Factorsin Computing Systems, 1859–1868.

WIEDENBECK, S. 2005. Facilitators and inhibitors of end-user development by teachers in a school environment.In Proceedings of IEEE Symposium on Visual Languages and Human-Centric Computing, 215–222.

WON, M., STIEMERLING, O., AND WULF, V. 2006. Component-based approaches to tailorable systems. In End-UserDevelopment. H. Lieberman, F. Paterno, and V. Wulf, Eds., Netherlands. Kluwer Academic.

WULF, V., PIPEK, V., AND WON, M. 2008. Component-based tailorability: Enabling highly flexible softwareapplications. Inter. J. Hum.-Comput. Stud. 66, 1, 1–22.

YAHOO! 2012a. Yahoo! Dapper web platform. http://open.dapper.net.YAHOO! 2012b. Yahoo! Pipes web platform. http://pipes.yahoo.com/.ZHOU, L. AND ZHANG, D. 2003. NLPIR: A theoretical framework for applying natural language processing to

information retrieval. J. Amer. Soci. Inf. Sci. Tech. 54, 2 115–123.

Received May 2012; revised September 2012; accepted December 2012


A Web-Centred Approach to End-User Software...

Documents

Transcript of A Web-Centred Approach to End-User Software...