Sven Ziemer. Trade-offs for web application development: understanding and improving current industrial practices

(1)

Sven Ziemer

Trade-offs for web application

development: understanding and

improving current industrial

practices

ISBN 978-82-471-1372-1 (printed ver.) ISBN 978-82-471-1372-8 (electronic ver.) ISSN 1503-8181

NTNU

Norwegian University of Science and Technology Thesis for the degree of

doctor

philosophiae

Faculty of Information Technology, Mathematics and

Electrical Engineering

Department of Computer and Information Science

Doctoral theses at NTNU,

(2)

Sven Ziemer

Trade-offs for web application

development: understanding and

improving current industrial

practices

Thesis for the degree of

philosophiae

doctor

Trondheim, January 2009

Norwegian University of

Science and Technology

Faculty of Information Technology, Mathematics and Electrical

Engineering

(3)

Thesis for the degree of philosophiae doctor

Faculty of Information Technology, Mathematics and Electrical Engineering Department of Computer and Information Science

©Sven Ziemer

ISBN 978-82-471-1372-1 (printed ver.) ISBN 978-82-471-1372-8 (electronic ver.) ISSN 1503-8181

Doctoral Theses at NTNU, 2009:02 Printed by Tapir Uttrykk

(4)

If you don’t know where you are going,

any road will do.

(5)

(6)

Abstract

When web applications are developed with a strong emphasis on time-to-market, the resulting development and trade-off practices are informal and make use of uncertain and fragmented knowledge. Developers and other stakeholders have to perform trade-offs using imprecise specifications, uncertain knowledge, and their beliefs, opinions and interests. In addition, this knowledge is frag-mented between the stakeholders, since each one holds his own views, opinions and interests. Performing trade-offs therefore involves sharing the stakeholders’ knowledge and interests before a balanced decision can be made.

The aim of this research is to understand how trade-offs are performed in web application development and to improve the current trade-off practices. In this research we have studied the development and trade-off practices in industrial web application development by interviewing eight Norwegian companies. The interviews with the companies identified real world problems that have been used further in the research. An analysis of the collected data has resulted in the discovery of several improvement opportunities for the applied trade-off practices. Working with these opportunities has resulted in a trade-off strategy and several trade-off tools. The trade-off strategy deals with the observation that many companies are unaware that they are performing trade-offs and that the trade-off tools use qualitative assessments of the stakeholders’ belief and opinion to perform such trade-offs. Two trade-off tools are tested experimentally by running a total of six experiments. The results of the experiments are used to improve a release planning method. By using real world problems from the interviewed companies the research has a realistic approach, yielding results that are relevant for industrial web application development.

The following contributions are claimed: First, it describes development practices found in eight small Norwegian Web Application development compa-nies, and focuses in particular on their trade-off practices. Second, a trade-off strategy to create awareness for trade-offs, and to enable knowledge sharing between stakeholders, is developed. Third, qualitative assessments of trade-off options are applied and tested, thus enabling prioritisation of trade-off options. Fourth, trade-off methods for enabling and facilitating knowledge sharing are developed. These include a release planning method that uses qualitative assess-ments to express the stakeholders’ beliefs and interests. Finally, a subprocess for managing change in web application development is provided, implementing a learning loop for knowledge management.

(7)

(8)

Preface

This thesis is submitted to the Norwegian University of Science and Technology (NTNU) for the doctoral degree – Doctor of Philosophy (PhD) The work has been part of the Websys project, which was financed by the Norwegian Research council (NFR), and has been carried out at the Software Engineering group, De-partment of Computer and Information Science (IDI) under the supervision of Professor Tor St˚alhane. I also had the opportunity to visit the IMSE group at Vrije Universiteit in Amsterdam (The Netherlands) for 10 months.

After working in industry for some years it was an exciting step to go back to university to start this PhD research. My hope was to build on my expe-rience as project manager for a software process improvement project, and to further improve my insight into how software processes and practices are shaped within companies. This was the start of my travel through my PhD research, which took me to some unexpected situations and experiences. With time, my research was motivated by understanding the social relations between the in-volved stakeholders, how they communicate and how each stakeholder seeks the fulfilment of his interests.

This travel has opened a new view for me, one which combines several disci-plines, such as software engineering, organisational theory, decision making and communication theory. When submitting this PhD thesis I thus feel that I have not come to an end but rather to a starting point for the continuation of this work.

Trondheim, 15 September 2008 Sven Ziemer

(9)

(10)

Acknowledgements

This work would not have been possible without the help, support, guidance, and inspiration of my colleagues, friends and family, and I am indebted to many. First of all, I am thankful to my supervisor Professor Tor St˚alhane, who encouraged me in my work, who was open to many questions and discussions, and who let me have the freedom to approach the research in my own way. A special thanks also to my second supervisor, Professor Monica Divitini, who was open to discuss issues on research methods and the research design with me, and to Professor Reidar Conradi, who advised me on the structure of the thesis, and who gave me valuable feedback on my thesis.

While working on my PhD thesis I made two wonderful friends: Siv Hilde Houmb and Xiaomeng Su. Most importantly, I am grateful for their friendship, which enriches my life. They have also supported me during my research work, and I would not have been able to complete this thesis without their support in difficult times. A special thanks to Xiaomeng for her help with the structure of this thesis and for her feedback.

A special thanks goes to Ilaria Canova Calori who helped me to design, run and analyse the experiments on the release planning method for web application development.

Part of my work was carried out at Vrije Universiteit in Amsterdam and I am thankful to Professor Hans van Vliet for hosting my stay.

Many colleagues have made my time at the Software Engineering Group at NTNU a memorable time, with many interesting discussions and social ac-tivities. My thanks go to Kirsti Elisabeth Berntsen, Birgit Krogstie, Jeniffer Sampson, Sobah Abbas Petersen, Gry Seeland, Anita Gupta, Thomas Øster-lie, Glenn Munkvold, Jingye Li, Darijus Strasunskas, Christian M¨onch, Øyvind Hauge, Gasparas Jarulaitis, and Geir Kjetil Hansen.

Thanks to the administrative staff, who helped me with many practical issues, and to Sari Cunningham, who proofread my thesis and helped to prepare this manuscript.

Finally, I want to thank my wonderful wife Kari for her love and for her enduring support, understanding and encouragement. You convinced me to accept this PhD position at NTNU while you were starting your own PhD work in Nijmegen (The Netherlands). I am indebted to you for all the experiences I made during my PhD work and the view this work has given me on my own future.

(11)

(12)

II Papers

83

7 Paper 1 85 8 Paper 2 101 9 Paper 3 109 10 Paper 4 115 11 Paper 5 123 12 Paper 6 133 13 Paper 7 141 14 Paper 8 155

A Interview guide template 173

B Notes from an interview 179

(15)

(16)

List of Figures

1.1 Research overview . . . 7

1.2 The contribution of this work . . . 12

1.3 The research activities of this research and their relation to the contributions and publications . . . 14

2.1 Comparison of trade-off approaches . . . 20

3.1 Overview of companies involved in the research . . . 32

3.2 The four research phases with the applied research methods . . . 33

3.3 Excerpt from a KJ-diagram – Negative experiences . . . 40

3.4 An Ishikawa diagram for an experience from figure 3.3 . . . 40

3.5 General model of an experiment . . . 42

3.6 The experiments in this research at a glance . . . 43

4.1 Web application development classification . . . 50

4.2 Lifetime phases of a web application . . . 51

4.3 Fragmented knowledge (part A) vs. shared knowledge (part B) . 54 4.4 Qualitative trade-off tool . . . 55

4.5 Five steps in qualitative trade-off assessment . . . 57

4.6 A combination of two SWOT analyses . . . 58

4.7 The configuration decision process . . . 60

4.8 The relation between the five experiments to evaluate the release planning method . . . 62

4.9 The effect of introducing a new method . . . 63

4.10 Subprocess for managing changes in the development environment 65 5.1 The contributions and their relation to the research approach and methods . . . 71

(17)

(18)

Abbreviations

AHP Analytical Hierarchy Process

ATAM Architectural Tradeoff Analysis Method AWE Agile Web Engineering

CBD Component Based Development CMC Computer-mediated Communication

COVAP Cost-Value Approach for Prioritising Requirements BBN Baysian Belief Network

EF Experience Factory

FMEA Failure Mode and Effect Analysis IFM Incremental Funding Method

KJ diagram Affinity diagram (devised byJiroKawakita) NRP Next Release Problem method

NTNU Norwegian University of Science and Technology OO Object Orientation

OOHDM Object-Oriented Hypermedia Design Method

OVAC The Optimising Value and Cost in Requirement Analysis method

QFD Quality Function Deployment

PG Planning Game

PMA Postmortem Analysis

PSERM Planning Software Evolution with Risk Management PWC Pair-Wise Comparison

RCA Root Cause Analysis

SEI Software Engineering Institute

SWOT analysis Strengths, Weaknesses, Opportunities and Threats analysis TPWC Tool Supported Pair-Wise Comparison

TTM Time-to-market XP eXtreme Programming UML Unified Modelling Language

(19)

(20)

Part I

Research context

and results

(21)

(22)

Chapter 1

Introduction

This chapter gives a short overview of the research work reported in this thesis. It starts with the problem outline for the research, and presents the research background and context. The chapter also shows how the research questions, the research design, the claimed contributions, and the papers that have been published as part of this research, are related.

1.1 Problem outline

Performing trade-offs in software development involves balancing several oppos-ing and interconnected factors in such a way that the outcome of each factor is acceptable for a given situation and for a given set of stakeholders. The task of performing a trade-off requires an understanding of how the involved fac-tors are connected, and how they affect the development project. Performing trade-offs under time pressure, and with incomplete and uncertain knowledge of the involved factors and potential consequences of each factor, adds to the complexity and difficulty of this task. This research addresses how trade-offs are performed in web application development [81, 69], and how trade-off prac-tices can be improved, given the development pracprac-tices applied in typical web application development projects.

This research focuses on web applications that are developed with a strong emphasis on time-to-market, and in competition with other web applications. While some web applications are developed in a traditional way, where web technology is only used for convenience, other web applications are developed with a strong emphasis on time-to-market and within a competitive context. In the latter case, the use of web technology enables development practices that focus on short time-to-market, rapid changes and continuously deploying new versions of an application. Web applications that are developed this way face a strong competition, that comes from two directions: (1) the competitors are ”only a mouse click away”, since their products are deployed on the Internet as well, and (2) every competitor would like users to return to their web application,

(23)

since many web applications are competing for the same users. Thus, developing web applications has two top priorities: to meet the users’ expectations and to develop applications within the time constraints with respect to competing web applications. The priorities, however, are in conflict with each other and leave the developers with the task of performing trade-offs between time-to-market and quality issues of an application. An informed trade-off depends on the developers’ abilities to assess the consequences of their choices and to negotiate between the conflicting priorities.

Web application development is characterised by (1) small development teams, (2) many small software deployments, (3) involvement of several stake-holders from non-technical fields, (4) informal and anecdotal specifications or requirements, and (5) short deadlines. Developers depend on their domain knowledge when developing web applications since these development practices involve mainly tacit knowledge. These development practices may also be found elsewhere. However, what makes web application development special is the in-tensity with which these practices are applied [81].

Typical trade-offs in web application development involve factors such as time-to-market, functional requirements and quality attributes. Examples in-clude application scalability (how many users can use an application simultane-ously), portability (how many browsers are supported) and performance (how long does a user have to wait for a response). The outcome of such trade-offs has an effect on when new functionality is deployed and to what degree the users’ expectations are met. Both priorities – time-to-market and quality – have their supporters among the stakeholders of an application. Each stakeholder seeks the fulfilment of his needs and wishes that corresponds to his interests and goals. Hence the conflict between these two priorities will also be found between the stakeholders.

The problem is to facilitate a resolution of the conflicting priorities between the stakeholders and to negotiate a way to balance the factors. This has to be done without a precise specification of the quality attributes involved, without explicit knowledge about the consequences of the available options, and on the fly. Without a precise specification of requirements and the lack of explicit knowledge about the development activities, consequences of candidate choices can only be described and compared imperfectly [117].

To address this problem this research deals with two subproblems. First, can the stakeholders’ tacit knowledge about the development activities be con-verted into explicit knowledge [76]? The stakeholders have their opinions, expert judgement and experiences. How can this knowledge be expressed and used to assess different options of a trade-off? Second, can this knowledge be shared in such a way that the total knowledge reflects the views of all stakeholders? By reducing the expectation of one factor from optimal to something that is ac-ceptable, the outcome of other factors can rise to something that is acceptable to the other stakeholders. Can this ”give and take” between the stakeholders on their choices for each factor result in trade-offs with an outcome that in the end is more acceptable to a majority of stakeholders than the optimal fulfilment of a single factor is [33, 106]? This research focuses thus on expressing the

(24)

stake-1.2. RESEARCH CONTEXT 5

holders’ tacit knowledge and on sharing all stakeholders knowledge to perform a trade-off between two top priorities in web application development.

1.2 Research context

The research in this thesis is part of the WebSys project [100], a research project financed by the Norwegian Research Council. The objective and the research goals of the WebSys project [100] are

”. . . to provide a better overall understanding of the trade-off be-tween time-to-market and reliability in developing Web-based sys-tems. This understanding will manifest itself as better methods and standard processes that can be applied, tested and refined through empirical work in Norwegian software companies. By this, we will gain insight into and improve the companies’ development processes”.

Main goal: To develop guidelines for the industrial development of timely and reliable Web-based systems.

Sub-goals:

G1Better understanding of the software process and related technologies on how to make trade-offs between time-to-market (TTM) and reliability.

G2Contribute to better methods for Web-based systems development where reliability and TTM need to be considered together.

G3Dissemination and exchange of the gained knowledge, with a strong inter-national component.

The project description calls for co-operation with Norwegian software com-panies. Contact was made with eight companies for either an interview or a workshop on web application development. This provided this research with an understanding of industrial web development.

The results of this PhD research have been published at international work-shops and conferences. In addition, an international workshop on trade-offs was organised by the Websys project in 2006.

1.3 Research questions

The research questions for this research have been formulated incrementally. An initial set of research questions was formulated before the research started. During the course of the work they have been revised and influenced by the results and feedback of this research. The aim of this research is twofold: to understand how web applications actually are developed (and in particular how

(25)

trade-offs are performed), and to improve the development practices in perform-ing trade-offs of this type of software development. This has led to four research questions:

RQ 1: What characterises Web Application Development?

RQ 2: How are trade-offs performed in web application development, and how are trade-offs performed that involve time-to-market as a factor?

RQ 3: How can trade-offs in web application development be improved?

RQ 4: How is knowledge transferred within web development teams?

1.4 Research design

The research questions are dealt with using several research phases and method-ologies. The research is done in co-operation with companies that are developing web applications, and therefore web development within these companies can be studied and real world problems identified.

This led to a research design with four phases. Each phase addresses at least one of the research questions, and contributes to the results of this research. An overview is given in figures 1.1 and 1.3, and the research approach and research phases are described in sections 3.1 and 3.2. This research is iterative, in the sense that the phases are used a bit ”back and forth”, and not executed in a sequential manner. The results from one phase may affect not only the next phase but also the previous phase. A brief description of the research phases is given below.

1. Data collection phase – Here, data are collected on industrial web de-velopment, and trade-off practices used for time-to-market are collected. Another objective for this phase is to identify problems and opportunities for co-operation with the companies. The problems have to be related to the companies’ development and trade-off practices in web application development, and should be feasible for finding improvements.

Relevant research methods: The qualitative research interview and Post-mortem Analysis.

2. Analysis phase– Here, we build up an understanding of industrial web application development and of the factors that influence the performed trade-offs. Other relevant issues are to understand how development prac-tices emerge, and on what assumptions trade-offs are made.

Relevant research methods: Grounded theory, and applying a framework to understand how development practices emerge [98, 68].

3. Construction phase – Here, some of the identified problems and co-operation opportunities are selected for further work. The objective is to improve the development and trade-off practices and to solve the problems,

(26)

1.4. RESEARCH DESIGN 7 Research Phases 1. Data Collection 2. Analysis 3. Problem Solving 4. V alidation Research questions RQ 1, RQ 2 RQ 1, RQ 2 RQ 3, RQ 4 RQ 3, RQ 4 Contribution C1 C1 C1, C2, C3, C4, C5 C4 Research methods Interview Post Mortem

Analysis

Literature study

Grounded

Theory

Root cause analysis

Experimentation Interview Publications None. P3: W eb Application

Development and Quality – Observations from in

-terviews with companies in Norway

P1: The use of Trade-of fs in the Development of W eb Applica -tions P4: A decision modelling ap

-proach for analysing require

-ments configuration trade-of

fs in time-constrained W eb Applica -tion Development P5: T rade-of f’s in W eb

Application Development – How to assess a trade-of

f opportunity

P8:

Managing change in soft

-ware development P2: T rade-of f Analysis in W eb Development P6: Knowledge sharing

through a simple release planning method for web application development P7:

An experiment with a

release planning method for web application develop

-ment

Other

–

Initial research questions

–

Identification of “problem situation”

–

Research question revised

–

Analysis of “problem situations”

–

1.5 Papers

The following eight papers have been published as part of this research. Figure 1.1 shows how these papers relate to the overall research design and the research questions. Papers P1 – P8 are included in part II of this thesis. A short description of the papers is shown below:

P1: Sven Ziemerand Tor St˚alhane: The use of Trade-offs in the Devel-opment of Web Applications. In Proc. First International Workshop on Web Quality (WebQuality 04) at 4th International Conference on Web Engineering (ICWE 2004), 27-28 July 2004, Munich, pp. 269-281. Also printed in Maristelle Matera and Sara Comai (Eds.): ”Engineering Ad-vanced Web Applications”, In Proc. Workshops in Connection with the 4th International Conference on Web Engineering (ICWE 2004), Munich, Germany, 28-30 July, 2004. Published by Rinton Press, ISBN 1-58949-046-0.

This paper presents a trade-off tool inspired by the Quality Function De-ployment method (QFD) [3]. The tool uses a simple qualitative assess-ment to evaluate the consequences of an option in a decision, with respect to other requirements and quality attributes. This makes it possible to compare different options and to perform a trade-off, knowing the conse-quences.

P2: Sven Ziemer, Tor St˚alhane and Magnar Sveen: Trade-off Analysis in Web Development. International Conference on Software Engineer-ing, 3-WoSQ: Proceedings of the third workshop on Software quality, pp. 70–75, ACM Press, 2005. In Xiaoqing (Frank) Liu, Yan Sun, Gautam Kane, Yuji Kyoya, and Kunio Noguchi (Eds.): Proc. Third Workshop on Software Quality, held at the 27th International Conference on Software Engineering (ICSE’05), St Louis, Missouri, May 17, 2005. Published by ACM, ISBN 1-59593-122-8, pp. 70–75.

(28)

1.5. PAPERS 9

This paper reports on a student experiment to evaluate the trade-off tool presented in paper P1 [124]. The experiment is a one factor experiment with two treatment design, comparing the trade-off tool with an ad-hoc approach to select an option for a decision. The results of the experiment showed that the groups using the trade-off tool experienced fewer diffi-culties in making the selection, fewer conflicts between the stakeholders, and a better consensus on the final decision. However, the groups using the trade-off tool also experienced their communication as less construc-tive. Taken together, the experiment showed that performing a trade-off became easier by using the provided trade-off tool.

P3: Sven Ziemerand Tor St˚alhane: Web Application Development and Quality – Observations from interviews with companies in Nor-way. In José A. Moinhos Cordeiro, Vitor Pedrosa, Bruno Encarna¸cão, and Joaquim Filipe (Eds.): Proc. Second International Conference on Web Information Systems and Technologies: Internet Technology / Web Interface and Applications (WEBIST 2006), Setúbal, Portugal, April 11– 13, 2006, Vol. 1. Published by INSTICC Press, ISBN 978-972-8865-46-7, pp. 495–498.

In this paper, results from interviews on development practices with seven companies that develop web applications are reported. The results pre-sented here are on development practices for requirements, quality issues and development process. The interviews revealed that most companies did not have a clear trade-off strategy, and that the most important qual-ity issues for the developers were related to the user’s experience of using an application.

P4: Sven Ziemer, Pedro R.F. Sampaio and Tor St˚alhane: A decision mod-elling approach for analysing requirements configuration trade-offs in time-constrained Web Application Development. In Proc. Eighteenth International Conference on Software Engineering and Knowl-edge Engineering (SEKE 2006), San Francisco, 5-7 July 2006. Published by Knowledge System Institute Graduate School, Skokie, IL, USA, ISBN 1-891706-18-7, pp. 144–149.

This paper presents a release planning method for web application devel-opment. The method uses a value based assessment of requirements. It gives guidance on the construction of candidate releases that fit within the time constraint and supports the decision on the final release. The method is consensus driven, and facilitates knowledge sharing between the involved stakeholders.

P5: Sven Ziemer and Tor St˚alhane: Trade-off’s in Web application development – How to assess a trade-off opportunity. In Jos´e Cordeiro and Slimane Hammoudi (Eds.): Proc. Third International Con-ference on Web Information System and Technologies (WEBIST 2007), Barcelona, Spain, March 3–6, 2007. Published by INSTICC Press, ISBN 978-972-8865-78-8, 8p.

(29)

Trade-offs with respect to time-to-market often involve quality attributes. With no specification it is the developers’ task to assess what are accept-able levels for important quality attributes of a web application. However, these acceptance levels will change, and with the informal development practices found in most companies, it is hard to be aware of the change in the end-users’ expectations. The trade-off tool presented here uses a series of SWOT analyses [45] to assess the options in a trade-off, and uses a cross analysis to compare them with the current context of an application.

P6: Sven Ziemerand Ilaria Canova Calori: Knowledge sharing through a simple release planning method for web application develop-ment. In Daniel Cooke et al. (Eds.): Proc. Nineteenth International Con-ference on Software Engineering & Knowledge Engineering (SEKE 2007), 9–11 July 2007, Boston, USA. Published by Knowledge System Institute Graduate School, Skokie, IL, USA. ISBN 1-891706-20-9, pp. 686-691. This paper reports on a student experiment to evaluate the release plan-ning method for web application development presented in P3 [123]. The experiment uses a one factor with two treatment design, comparing the release planning method with an ad-hoc release planning approach. Af-ter the experiment, the students fill in a post-experiment questionnaire, with questions regarding knowledge sharing, understanding, consensus, requirement prioritisation and stakeholder satisfaction. The results show that the control groups using the ad-hoc approach performed better on knowledge sharing and understanding, while the treatment group using the release planning method performed better on the remaining factors.

P7: Sven Ziemer and Ilaria Canova Calori: An experiment with a re-lease planning method for web application development. In Pekka Abrahamsson, Nathan Baddo, Tiziana Margaria, and Richard Messnarz (Eds.): Proc. 14th European Conference on Software Process Improve-ment (EuroSPI’2007), 26–28 September 2007, Potsdam, Germany. Pub-lished in Springer LNCS 4764, ISBN 978-3-540-74765-9, ISSN 0302-9743, pp. 106–117.

This paper reports the results from four experiments with the release planning method presented in P3 [123]. The experiments are planned and operated as the first experiment in P6 [122]. The experiments are planned to test how experience in using the release planning method af-fects knowledge sharing and understanding, and what effect an improved communication style in using the release planning method has on knowl-edge sharing and understanding. The results show that in both cases the treatment group using the release planning method improved in knowl-edge sharing and understanding, compared to the control group that used the ad-hoc approach.

P8: Sven Ziemer: Managing change in software development. In: Lech Madeyski, Miroslav Ochodek, Dawid Weiss and Jaroslav Zendulka

(30)

1.5. PAPERS 11

(ed.): Software Engineering in Progress. In conjunction with 2nd IFIP Central and East European Conference on Software Engineering Tech-niques (CEE-SET 2007), Work-in-progress session, 10-12 October 2007, Poznan, Poland. Published by Wydawnictwo Nakom, Poznan, Poland, ISBN 978-83-89529-44-2, pp. 184–198.

In this paper, a process to manage the change that occurs in the context of web development is presented. The process presented in this paper aims at improving the trade-off practices, by facilitating a deeper understanding of the involved factors over time. This understanding is achieved by offering simple activities that plan, perform and evaluate a trade-off. A knowledge base for the project is created, and lessons learned are made available for other stakeholders.

In addition, this research has contributed to two other publications. Papers P9 and P10 are not included in this thesis, since they do not report on research results that answer any of the research questions. For reference, we include a small summary of the two papers here.

P9: Glenn Munkvold, Gry Seland, Siv Hilde Houmb andSven Ziemer: Em-pirical assessment in converging space of users and profession-als. In Proceedings of the 26th Information Systems Research Seminar in Scandinavia (IRIS’26), Helsinki, August 9-12, 2003, 14 p.

Implementing generic standardized systems in local practices often implies a process of change involving people from various domains and commu-nities. In this paper we put particular emphasis on the new emerging community of people this implies. Based on experience from the Software Engineering and HCI domain, we discuss a methodology supporting these new challenges. We use Communities of Practice as a possible conceptual framework, and action research as a methodological approach to better understand the ongoing situated activities and processes in practice.

P10: Ilaria Canova Calori, Tor St˚alhane and Sven Ziemer: Robustness analysis using FMEA and BBN – Case study for a web-based application. In Jos´e Cordeiro and Slimane Hammoudi (Eds.): Proc. Third International Conference on Web Information System and Tech-nologies (WEBIST 2007), Barcelona, Spain, March 3–6, 2007. Published by INSTICC Press, ISBN 978-972-8865-78-8, pp. 164-170.

Time pressure and quality issues represent important challenges for those who develop web-based systems. The ability to analyse a system’s quality and implement improvements early in the development life cycle is of great practical importance. For our study we consider robustness as a critical quality issue. Our objective is to propose a general framework for conduct-ing robustness analysis of web-based systems at an early stage of software development, providing a tool for evaluating failure impact severity and supporting trade-off decisions during the development process.

(31)

1.6 Contributions

The contributions of this research are assigned in three groups: Understanding web development practices, trade-off methods for web application development, and facilitation of knowledge sharing between stakeholders in web application development. An overview of the contributions and their relation with the published papers is shown in figure 1.2. Figure 1.3 shows in what order the different activities have been performed and how they relate to the publications and contributions.

Contribution Development practices Trade-off methods Knowledgesharing Paper

C1: Development practices X P3 C2: Trade-off strategy X P1 C3: Qualitative assessment of trade-off options X X P1, P2, P4, P5 C4: Enabling knowledge sharing X P6, P7 C5: Knowledge management X P8, P5

Figure 1.2: The contribution of this work

C 1 Web Development Practices A description of such practices in eight Norwegian companies, based on interviews and Postmortem Analyses with the developers and managers in the companies. The development practices include trade-offs between time-to-market and quality attributes.

C 2 Trade-off strategy for web application development Strategy based on the principles of (a) creating awareness for trade-offs, (b) balancing short and long term wishes, (c) sharing stakeholders’ knowledge, and (d) using qualitative assessment of options in trade-offs. The strategy is to utilise trade-offs by bal-ancing stakeholders’ interests, focusing on the opportunities, and by using the freedom of choice to find the means to achieve the opportunities.

C 2.1 Subprocess for change management(same as C 5.1) The research provides a subprocess for managing the change in web application development, using the trade-off strategy mentioned above.

C 3 Qualitative assessment of trade-off options and decision support

Here, several ways of assessing the options of a trade-off qualitatively are used. This enables prioritisation of trade-off options and gives valuable support for decision making in situations with mainly tacit and uncertain knowledge.

C 3.1 Trade-off tools for assessing optionsTools used to assess trade-off options under consideration qualitatively.

(32)

1.7. THESIS STRUCTURE 13

C 4 Trade-off methods for enabling and facilitating knowledge shar-ing Several factors that contribute to enable such sharing are tested. Knowl-edge sharing builds up a common understanding between stakeholders, and con-tributes to an assessment of trade-off options reflecting all stakeholders’ views.

C 4.1 Release planning methodEnables knowledge sharing between stake-holders, using qualitative assessments and a consensus driven decision process.

C 5 Knowledge management for web application development A learning loop to facilitate learning and to create a knowledge base to assist in trade-offs. The accumulated knowledge is used to manage web application projects in a rapidly changing context. Over time this will increase the confi-dence in the available knowledge.

C 5.1 Subprocess for change management A subprocess for managing change in web application development, which implements a learning loop and accumulates a knowledge base for web development projects.

1.7 Thesis structure

This thesis is divided into two parts:

• Part I presents the research questions, research results, and the evaluation of the research, as well as an introduction to the field, and puts the research into context. It covers chapter 1 – 6.

• Part II contains papers P1 –P8 listed in section 1.5. They provide detailed results and discussion of the individual research activities.

An overview of the chapters in part I is given below:

• Chapter 2 – Related WorksThis chapter covers related works in Web Engineering, release planning, knowledge sharing, trade-off methods and decision making.

• Chapter 3 – Research Methods This chapter presents the research approach, research phases and research methods that have been applied in this research.

• Chapter 4 – ResultsThe results of this research are presented, covering a description of development practices, a release planning method for web development, and a process for managing change in web development.

• Chapter 5 – Evaluation The research in this work is evaluated, by revisiting the research questions and by linking the research to the research goals.

• Chapter 6 – Conclusion and further workThe final chapter of part I concludes the work done and points out directions for future research.

(33)

T

imeline =

Infl

uence between

two studies=

Activity 1: Interview I PMA

I

Activity 4: _{Interview II} PMA

II Activity 2: Analysis I Activity 3: _Qualitative trade-of f tool Activity 5: S tu d e n t e xp e rim e n t (E 0 ) P2 P1 Activity 6: Analysis II P3 C1 C1 C2 C3 Activity 8: T ra d e -o ff a ss e ss m e n t P5 C2 C3

Activity 7: Release planning method

P4 C4 C3 Activity 1 1: Change process P8 C5 C3 C4 Activity 9: S tu d e n t e xp e rim e n t (E 1 ) P6 C4 Activity 10: S tu d e n t E xp e rim e n t (E 2 .1 – E 3 .2 ) P7 C4

Data Collection Phase

Construction Phase Analysis Phase V alidation Phase Activity 1 : Interviews with 4

companies and a PMA

with 1

company Activity 4:

Interviews with 8

companies and a PMA

with 1

company Explanation: Px = Paper (see section 1.5) Cx = Contribution (see section 1.6)

Figure 1.3: The research activities of this research and their relation to the contributions and publications

(34)

Chapter 2

Related work

This chapter gives a view on the related works for web engineering, trade-off analysis methods, release planning methods, decision making and knowledge sharing, and thus shows the research context that this work took place in. These fields are related to work in this thesis and have inspired and guided the work done for this thesis. An evaluation of this work’s results with respect to the related work will be given in section 5.4.

2.1 Web Engineering

The aim of studying the literature on web engineering is to get an understand-ing of how web applications are developed and what development practices are applied to do so. Another point of interest is to understand how development methods for web applications are constructed to support the distinct character-istics of web applications and development practices to develop them.

Web engineering is a subdiscipline of software engineering and studies the development of web applications and systems. A definition of this discipline was given by Murugesan et al. [73]:

Web engineering is the establishment and use of sound scientific, engineering and management principles and disciplined and system-atic approaches to the . . . development, deployment and maintenance of high quality Web-based systems and applications.

Not all researchers view the development of web applications as a sepa-rate discipline, but rather as a new application domain of software engineering [52]. However, all agree that web application development has some distinc-tive characteristics, and that a systematic and disciplined approach to develop web applications is needed. All experts agree to avoid ad-hoc development ap-proaches which result in a crisis of web application development [7]. Without a disciplined approach, web applications will neither deliver the desired quality

(35)

nor be developed on time. Web application development calls for continuous up-dates and refinements, which constitute an evolution of the application without specific releases (as opposed to traditional software development). This makes web application development behave like gardening. The gardening metaphor raises the question if an engineering approach is appropriate for web application development. Murugesan et al. [73] believe that engineering principles need to be adapted to the web environment. Developing web applications is different from developing other software applications, for a number of reasons. First, the web is both an application and a delivery medium. Web applications have a greater focus on the look and feel, and incorporate multimedia at various degrees in presentation and interface. This results in a greater bond between art and science. Finally, web applications are developed within a short time frame, thus making it difficult to apply the same level of formal planning used in traditional software development.

Web engineering is a multidisciplinary field, combining traditional software engineering disciplines such as requirement engineering, evolutionary system development and security, with disciplines such as graphical design, copyright and intellectual property rights, multimedia and hypermedia [28, 73].

2.1.1 Web development practices

Development practices in web application development are of particular interest to this research. Several studies on web development practices are found in the literature and are briefly presented here.

In their study of web application development Ramesh et al. [81] focus on understanding the features that characterise web application development. The study involves nine companies developing web applications in the US. The main finding of this study is that there are special web application development prac-tices and that they are caused by three factors: demand for rush to market, operating in a different kind of market environment, and the lack of experience in developing such products. The resulting web application development prac-tices are characterised by parallel development activities, release orientation, tool dependence, customer involvement, prototyping, fixed architecture, com-ponents, ignored maintenance, and tailored methodology. Some of the practices are further described and analysed in [9]. The characteristics of web application development practices are not necessarily unique for web application develop-ment, and may be found in traditional software development as well. However, the intensity with which they are applied is unique for web application devel-opment. Another issue raised by this study is that of a different development culture. The culture of web application development ”appreciates less structure, smaller teams size and diverse team compositions”. The development culture is, however, evolving together with the product, and when the market demands quality and maturity over speed, the development culture begins to resemble traditional software development.

A survey of web engineering in practice by McDonald et al. [70] identifies similar practices. In this survey, web application development practices are

(36)

2.1. WEB ENGINEERING 17

identified and described as a first step to developing a web application develop-ment process. Such a process has to address practices such as short developdevelop-ment life-cycle times, multidisciplinary teams and small development teams working in parallel on similar tasks.

Yusop et al. [117] performed a study on five web application development projects with companies from Singapore. In this study they addressed the im-pact of non-functional requirements in web application development projects, and found that non-functional requirements are not specified sufficiently. This is often due to uncertainty about the customer’s needs, lack of time and lack of knowledge of the importance of non-functional requirements. Functional re-quirements are, however, specified in a structured manner. Two non-functional requirements that are important to the companies in this study are security and integration with other systems. As a result of the insufficient specification of non-functional requirements, developers have to rely on previous experience in developing similar systems.

In a survey of Jordanian web companies conducted by El Sheikh et al. [95], it is shown that small web application development companies find it hard to apply web engineering practices such as web metrics, standards and procedures, control of the development process and organisation issues. The survey was carried out by using the Software Best Practice Questionnaire from ESI [48]. No explanation other than a difference between European companies and small web application development companies in Jordan is given. However, this study stresses the same points as the studies cited above, such as small development teams, tight time constraints and lacking experience in developing products under these circumstances.

The development of web application has some distinctive characteristics, as shown by these surveys. These include small development teams, tight time constraints, short development cycles with frequent updates, a multidisciplinary nature of development activities, and a development culture that appreciates less

structure. None of these characteristics are exclusive for web application

devel-opment, and can be found in other application domains as well. However, what makes web application development different from other application domains is

theintensity with which these practices apply [81].

2.1.2 Web development methods and tools

A number of software development methods for web application development have been constructed to address the special characteristics of web applications. This is the case for web design methods that address the special ways of de-signing web applications. One such method is the Object-Oriented Hypermedia Design Method (OOHDM) [93, 85] that uses a five-step process to build a web application. This method applies models for both the conceptual design, navi-gational design and the interface design, using UML with some small extensions. Other design methods are HDM [37], W2000 [6], WebML [18] and Autoweb [35]. A commonality is that web applications are generated from platform indepen-dent models. These models focus on the web interface of the applications and

(37)

on the structure of the information that is presented.

Another field where specialised web methods are found is quality modelling. The WebQEM quality model for web applications has been developed by Olsina et al. [79, 78]. This model addresses the quality of some distinct features of web applications, such as the fact that web applications are content-driven, document-oriented and user-centred and that searching and browsing are im-portant functionalities for web applications. Imim-portant quality requirements for web applications are therefore information accuracy, information suitability, accessibility and legal compliance.

Several development processes for Web application development have been proposed, such as Web OPEN [44] and Agile Web Engineering (AWE) [71]. The Web OPEN process is an extension of an established object-oriented develop-ment process, that is also well suited for component-based developdevelop-ment (CBD). To support web development, it is extended with new activities, tasks, tech-niques and roles. Among the distinct characteristics of web application that are addressed are architecture, content management and requirements engineering. The AWE process focuses on the multidisciplinary nature of web engineering, and stresses the many roles involved in web application development and how they have to work together. AWE includes roles that reflect both the business, domain and creative design models. In addition, traditional software develop-ment roles are included.

All development methods constructed for web application development aim at supporting several distinct characteristics of web application development. They do so, however, in different ways. The methods described in this section can be divided into two different approaches: One approach is the model-based methods, focusing on the content and navigational sides of web applications. These methods assume the use of a disciplined development approach with de-velopers that can model applications using a language like UML. A second approach is taken by the development processes, which focuses more on the software development practices and aims at supporting them. The Web OPEN process focuses on the contents level, as do the model-based approaches. How-ever, the Web OPEN process does so by including new roles and tasks and extends a traditional development team. The model-based approaches intro-duce a model-driven paradigm to software development, which has not been found in use among web application development practices as discussed in the previous section.

2.2 Trade-off analysis methods

Trade-off analysis methods are found in several fields where conflicting aspects need to be balanced. In the Oxford Dictionary of English, a traoff is de-fined as a balance achieved between two desirable but incompatible features. By studying trade-offs for software architecture, requirements en-gineering, and software processes and development practices, we search for an understanding of how trade-off methods are functioning. In particular, the

(38)

fol-2.2. TRADE-OFF ANALYSIS METHODS 19

lowing four questions are of interest to this research: (1) How are conflicting aspects of a decision identified? (2) How are conflicting aspects of a decision analysed? (3) How are candidate options for a decision analysed? and (4) How are trade-offs settled and what is the stakeholders’ role in this process?

Trade-off methods for architectural trade-off analysis and requirement priori-tisation trade-off analysis are presented, in order to answer the aforementioned four questions. In addition, five of the presented trade-off methods are sum-marised and compared to each other in figure 2.1.

2.2.1 Architectural trade-off analysis

In an architectural trade-off analysis, we assess to what extent quality re-quirements are met by a software architecture [10]. One of the best known trade-off methods is theArchitecture Tradeoff Analysis Method(ATAM) [22, 58, 57]. This method has been developed by the Software Engineering In-stitute (SEI) for the analysis of software architectures with respect to multiple quality attributes. It aims at locating and analysing sensitivity points and trade-off points. To do so, ATAM uses scenarios that cover both the planned use of the system and future growth of the system. ATAM consists of 10 steps grouped into four phases, and is organised as a workshop with up to 40 stakeholders. Sensitivity points and trade-off points are identified for conflicts between the quality attribute utility tree, architectural approach and scenarios about how the system will be used.

In ATAM, conflicts between quality attributes, architectural approaches and planned and future use of the system are identified by a qualitative analysis. This evaluates if the architectural approaches answer the needs of the quality attributes and scenarios. This identifies the sensitivity and trade-off points. The focus is thus not on analysing the conflicting aspects, but on identifying and locating them. Finding options for trade-offs and settling trade-offs are not part of ATAM. However, ATAM is developing the architecture in an iterative approach, and the architecture is improved by the architect in an incremental fashion [119]. Stakeholders are involved in this evaluation both by providing scenarios and by contribution to the analysis.

ATAM can be used together with the Cost Benefit Analysis Method

(CBAM), which is another method from the Software Engineering Institute [56, 77]. This method helps architects to evaluate the cost and benefits of potential solutions to the trade-offs identified by the ATAM method.

In an approach calledTradeoff and Sensitivity Analysis in Software Architecture Evaluation by Zhu et al. [119], the Analytical Hierarchy Pro-cess (AHP) is used to evaluate potential software architecture designs. This approach starts with trade-offs that are already identified and takes into con-sideration all quality attributes, priority weights of design alternatives for in-dividual quality attributes, and priority weights among the quality attributes themselves. Using AHP makes it possible to consider trade-offs in relative terms when there exist no precise specifications of quality attributes. This approach also aims at making the decision consequences more explicit, something that is

(39)

Domain Architecture evaluation Requirment prioritisation Method Architecture T rade-off Analysis Method

By: Kazman et al. (1998) and Clements et al. (2002)

Tradeoff and Sensi

ti vity Analysis in Soft ware Archi tec ture Evaluation By Zhu et al. [1 17] Goal-oriented Analy

-sis Method By:

Yamamoto et al. (2008)

Cost-value require

-ment prioritisation By: Karlsson et al. (1997) Trade-off analysis for requirements selection By: Ruhe et al. (2003)

Identification of conflicting aspects Group evaluation of scenarios, quality attribute utility tree and architectural approaches

Identified as trade-of

f

points (e.g. by using ATAM) Project constraints: requirements and time-to-market modelled in goal- graph with annotated attributes Project constraints: requirements and time-to-market

Project constraints: requirements and time- to-market

Analysis of con

-flicting aspects

Defined as sensitivity points and trade-of

f

points; handled indi

-vidually

Consi

ders all quality at

-tributes, priority weights of design alternatives for individual quality attri

-butes and priority weights among the quality at

-tributes themselves

W

eighting of an

-notated attributes in goal-graph; multiple criteria are possible

Pairwise comparison of both cost and value using

AHP

Requirements are divid

-ed into several classes. Pairwise comparison of stakeholder preference between classes, and for all requirements within a class

Analysis of can

-didate options

Based on incremental improvement, thus no consideration of several options Calculation of relative priority of design alterna

-tives using

AHP

All possible candidate options are analysed, using

TOPSIS

Uses cost-value dia

-gram to compare can

-didate requirements

Selection of candidate requirements

Settlement of trade-of

fs

Incremental process that develops the sys

-tem architecture

Optimisation based

Optimisation of best trade-of

f; final deci

-sions made by stake

-holders

Discussion involving stakeholders, decision by project manager

Trade-of

f analysis for

candidate requirements selection using heuristic approach

Stakeholder involvement Evaluation can involve all stakeholders; involves usually archi

-tect and several other stakeholders Prioritisation of design alternatives is performed by a single stakeholder

The approach uses multiple attributes that can be evaluated by a single stakeholder each Involves customer and users for value, and developers for cost prioritisation; decision by project manager

Prioritisation of require

-ments is performed by a single stakeholder

(40)

2.2. TRADE-OFF ANALYSIS METHODS 21

usually hidden in standard AHP practice. The approach by Zhu et al. thus de-pends on several architecture design options that are weighted for each quality attribute. While ATAM involves a potentially large number of stakeholders in the evaluation of the architecture, Zhu’s approach involves only one stakeholder for assigning the priority weights.

2.2.2 Requirement prioritisation trade-off analysis

In iterative software development, a software system is developed and deployed in increments, where each increment implements a subset of the system’s func-tionality. This opens for deploying the most important requirements early in the development, and for gaining benefits of the system early [42]. This makes release planning and requirement prioritisation important activities, since they make decisions on which functionality is most desired by the customers [12].

Trade-off methods for requirement prioritisation are presented in this section and release planning methods are presented in section 2.4. A general overview of techniques for requirement prioritisation is given in [12] and [54].

In a recent paper, Yamamoto et al. [114] present the Attributed Goal-Oriented Analysis Method for Selecting Alternatives of Software Re-quirements. This approach uses goal-oriented requirement analysis [26] to de-tect dependencies among requirements, and a multi-criteria method Technique for Order Preference by Similarity to Ideal Solution (TOPSIS) for evaluation of requirements. Using a goal graph, the alternatives are identified and augmented with attributes and calculation rules. The calculations are used in the evalua-tion to find an ideal soluevalua-tion of the criteria under consideraevalua-tion. The result of the analysis is used as an input to the decisions made by stakeholders.

In theTrade-off analysis for requirements selection(TARS) approach by Ruhe et al. [86], AHP is used to balance the stakeholders’ preferences. Re-quirements are organised in requirement classes, and the prioritisation is done in two steps: first, the requirement classes are prioritised, and then, the re-quirements in each class are prioritised. This reduces the number of pair-wise comparisons in AHP. The further steps of this method consist of identifying candidate requirements, and a trade-off analysis of requirements selection un-der resource and quality constraints. This is done in a heuristic approach with two operations: rebalancing and modifying. The first operation gradually re-laxes other criteria to remove constraint violations, and tries to stay within limits for all defined constraints. The latter operation reduces and extends the requirement class under investigation. The final decision can then be made from a small number of alternatives.

Liu [66] presents an approach to requirement prioritisation based on a trade-off analysis between the satisfaction degree of requirements and the marginal rate of substitution in decision science. Using this approach, software quality requirements are classified to be either hard or soft. Hard quality requirements must be satisfied and soft quality requirements can be satisfied to some degree. The soft quality requirements are prioritised relatively by analysing the trade-offs between the satisfaction degrees of conflicting quality requirements, and

(41)

by the customers’ trade-off between attributes on which requirements impose constraints, based on the marginal rate of substitution in decisions science.

Another approach that uses AHP is the Cost-value requirement pri-oritization approach by Karlsson et al. [53]. This approach uses two AHP prioritisations: the customers and users apply AHP’s pair-wise comparison for the relative value of each requirement, while an experienced developer does the same for the relative cost of each requirement. Using a cost-value diagram the stakeholder discusses the candidate requirements and the final decision is made by a project manager.

Common for all four requirement prioritisation trade-off analysis methods presented here, is that the conflicting attributes are given by the context: de-velopment effort vs. project constraints, such as time-to-market or available re-sources. All methods aim at finding a subset of requirements that fulfil project constraints such as time, quality and cost. The methods are, however, different in how the conflicting aspects are analysed and how candidate requirements are analysed. Two methods use AHP and depend on the pair-wise comparison of requirements to a criterion stated by the method (stakeholder preference or cost-value). The other methods use stakeholder satisfaction or let their users define multiple criteria for the analysis. Finally, the methods differ in how can-didate alternatives are assessed and how trade-offs are settled. All cancan-didate alternatives are identified in the Goal-Oriented Analysis method before the opti-mal alternative is calculated, using multiple criteria. TARS uses the result from the AHP prioritisation for stakeholder preference to select candidate require-ments and uses a heuristic trade-off analysis to find a solution. The Cost-value requirement prioritisation method uses two criteria for the AHP prioritisation and uses a cost-value diagram for a final selection.

2.3 Development practices trade-off analysis

Development teams can choose among several development practices, and choos-ing among them involves trade-offs on aspects such as development performance or the quality of the final product. While it is straightforward to identify con-flicting aspects between development practices, it is much harder to understand the consequences that the choice of development practices may have [67]. The development practices are selected by the developers and the project manager. In most cases this selection is done based on prior experience.

In a study on development practices in a large corporation, MacCormack et al. [67] collected data on eight development practices and investigated the impact of these practices on productivity and quality. Selecting more flexible development practices can have a productivity penalty as a trade-off. However, this trade-off can be overcome by selecting a coherent system of development practices. By using a multivariate model of defect rate and productivity, de-velopment practices that did not have a significant relation on productivity or quality when considered alone have a strong impact when considered together with other practices. The study shows that some trade-offs can be overcome

(42)

2.4. SOFTWARE RELEASE PLANNING 23

by selecting a coherent system of development practices. Among the practi-cal implications of this study is that development practices should be chosen depending on the project and that the selection should be driven by primary performance objectives for a project. For the development practices that are investigated, this study illustrates how they have an influence on each other and provides some guidance in finding the ”coherent system of development practices”. Finding such a coherent system, however, depends on the project objectives and making a decision is left to the developers and project manager. When comparing agile and disciplined development practices, Boehm et al. [16] identify five critical factors – size, criticality, dynamism, personnel and culture – that are ”involved in determining the relative suitability of agile or plan-driven methods in a particular project situation”. These factors are used to perform a trade-off between agile and plan-driven development practices. The authors use the term Middle Ground for a mix of agile and plan-driven development methods. The conflicting aspects in this trade-off are agile vs. plan-driven development. Using the critical factors in a project assessment, the developers and the project manager can choose the right balance between agile and plan-driven development for each factor.

2.4 Software release planning

Software release planning is the task in which it is decided which customer gets which features and quality at which moment [19]. Release planning thus addresses the decision to select features for a product release. The features give the customers value. At the same time, a release has to satisfy technical, resource, budget and risk constraints [88]. Among the issues that have to be taken into consideration when making a release decision are available resources, milestones, conflicting stakeholder views, available market opportunity, risks, product strategies, and cost.

As incremental software development replaces monolithic software develop-ment, a series of releases is offered to the users and customers with additive functionality. Incremental development gives the customers an early sense of value and the opportunity to provide early feedback. At the same time it gives the developers an early return on their investment .

Release planning is an important activity. Without a good release plan important critical functions can be delayed, resulting in dissatisfied customers. A good release plan, thus, can ensure that the most important requirements are deployed first. Incremental software development is sensitive to changes or additions to requirements, and as new releases are planned, the notion of what the important requirements are may have changed.

2.4.1 Release planning methods

Several release planning methods are described in the literature. In order to compare the methods, Saliu and Ruhe [92] present ten key aspects of software

(43)

release planning. These aspects are used to evaluate release planning methods, and to illustrate the differences between them. Important dimensions are the objectives, the prioritisation mechanism, the stakeholder involvement, the re-source and system constraints, and the scope. The objective of a research plan-ning method is typically a mix of aspects such as value, urgency and risk. The stakeholder involvement addresses issues such as what stakeholders to involve, if the stakeholders are equally important, and when and how they are involved. The scope of a release planning method refers to the number of releases that are considered in a release planning decision. Requirements are prioritised by expressing their priority relative to the other requirements. This can be done by using scales of different granularity or by voting schemes where the stakehold-ers can prioritise the requirements. A release planning method has to consider several constraints, such as interdependencies between requirements, budget or an impact analysis of the consequences of implementing the requirements.

Two common approaches to release planning are (1) applying human intu-ition, communication and negotiation between conflicting constraints and ob-jectives, and (2) applying an optimisation approach looking for the optimal result [88]. The human oriented approach is well suited to address stakeholder conflicts and to balance their interests and preferences manually. However, an exponential growth of the number of possible release plans makes it impossible to process the release plans manually. The human oriented approach works fine with Agile Development, where release planning relies on physical meet-ings between stakeholders for requirement prioritisation and conflict resolution. The optimisation approach assumes that the release planning problem can be formalised and that it can be solved as an optimisation problem. The Next Release Problem method (NRP) [5] assigns weights to customers according to how important they are for the software, and aims at finding the subset of cus-tomers whose features must be satisfied within the budget. The Optimising Value and Cost in Requirements Analysis (OVAC) method [50] selects features that give maximum value for minimum cost. This approach is better than th

Sven Ziemer. Trade-offs for web application development: understanding and improving current industrial practices

Sven Ziemer

Doctoral theses at NTNU,

Engineering

any road will do.

Preface

Acknowledgements

Contents

II Papers

Abbreviations

Part I

1.1 Problem outline

1.2 Research context

1.3 Research questions

1.4 Research design

Other

1.5 Papers

1.5. PAPERS 9

1.5. PAPERS 11

1.6 Contributions

Contribution Development practices Trade-off methods Knowledgesharing Paper

1.7. THESIS STRUCTURE 13

1.7 Thesis structure

Data Collection Phase

Chapter 2

2.1.1 Web development practices

2.1. WEB ENGINEERING 17

2.1.2 Web development methods and tools

2.2 Trade-off analysis methods

2.2.1 Architectural trade-off analysis

Tradeoff and Sensi

TOPSIS

2.2. TRADE-OFF ANALYSIS METHODS 21

2.2.2 Requirement prioritisation trade-off analysis

2.3 Development practices trade-off analysis

2.4. SOFTWARE RELEASE PLANNING 23

2.4 Software release planning