Managing change in software development Sven Ziemer Department of Computer and Information Science, Norwegian University of Science and Technology, NO-7491 Trondheim, Norway sven.ziemer@idi.ntnu.no Abstract. The software practices used to develop software systems emerge under the influence of a number of factors, including such factors as culture, size and criticality. These factors will change over time and the change must therefore be managed. Software practices that have emerged under the influence of factors that later has changed have to be adopted to reflect the change of influencing factors and thereby the context of a development project. Web applications are no exception and are operated in a changing environment. The continuous change takes place both with respect to their functionality, the technology used to implement an application, the development practices applied to develop them, and the environment they are deployed into. Managing the changing environment is a key factor to success. To be successful, change has to be coped with continuously. This paper proposes a subprocess to manage the changing environment of software applications and their development activities in a continuously way, using mostly qualitative information. 1 Introduction Change is an integral part of life, and brings both insecurity, opportunities and risks. We feel insecure in a time of change because we do not know what it will bring us and we may feel threatened by the risks that comes with the change. This can be used as motivation to spend time and effort to prevent change to happen at all. But we can also work to exploit the opportunities that comes with change and to build up barriers against the risks we are facing. In our globalised world this is more true than ever before. Many companies and organisation are relying on the proper functioning of their software systems. This involves both offering the right functionality and the right quality. As a consequence, there is an interest both in how software is developed, and that the software development team is aware of a changing environment, takes advantage of the opportunities and mitigate the risks that come along with change. Especially when there is a lot of competition between companies (as between competing web applications), it becomes important to react quickly and to be first out with new ideas and functionality. Understanding software practice is an important aspect in reacting to a changing environment. The applied software practice in a development project
is influenced by a number of factors, with the changing environment of a software application being one of them. Adjusting software practice in a changing environment becomes therefor part of adjusting to it and taking advantage of if. To exploit the opportunities of a changing environment and to avoid the risks of it, the change has to be monitored and managed. This should be an ongoing activity as the environment is changing continuously. For many small development teams there is only limited information available to monitor the changing environment. In addition, the information is mostly qualitative. In this paper, a subprocess for managing small software development projects in a changing environment is proposed, that aims at supporting especially applications developed with a strong emphasise on short time-to-market. This work emerged from studying web application development, and web application development will therefore be used as an example. The paper is organised as follows: The background for this work is presented in section 2, and related work is shown in section 3. Section 4 gives an overview of changes in the development practices that have been observed in web application development. A subprocess to manage the changing environment in software application development is shown in section 5. Finally, some conclusions are given in section 6. 2 Background The research in this paper has its origin in observing and studying web application development projects. The goal of this research was to understand and possible improve the way in which trade-off s involving quality attributes and time-to-market are performed in web application development. The implications of this work is, however, not limited to web application development but rather to software development projects that share a common set of characteristics and software practices. Web technology or web architectures are not the key factor identifying the development projects of interest for this research. The factors that identify the development projects of interest for this research are non-technical and related to the applied software practices. As part of this research, there is also a special focus on the emergence of software practices and on how software practices have to change over time in order to respond to the environment of a software development project. The software practices of interest are based on oral and ambiguous communication between the involved stakeholders, relying on tacit knowledge of stakeholders and the short time-to-market requirement for software applications. 2.1 Software development practice Software development is not an isolated activity but takes place in a broader context, with both technical and non-technical issues. The environment where software development takes place consist of the development project, of the organisations that are involved in the development project, of competing software projects and of potential customers expectation and demands. These are just
some elements that are part of the complex environment where software is developed. The way in which software is developed is influenced by its environment. Techniques and methods that are used in the development activities are selected based on an assessment of the environment of a software application. This is the case when a decision between an agile approach and a traditional approach to software development has to be made. This is also the case when a decision has to be made on what activities are to be included into the development of a software application and how they are to be performed. The success of agile software development methods such as Scrum or extrem Programming provides software developers with an alternative to plan-driven methods. Traditional software development methods plan-driven methods are characterized by a systematic engineering approach to software that carefully adheres to specific processes from requirements to finished code. Agile methods are characterised by short iterative cycles, user involvement, relying on tacit knowledge within a team and self organising teams [1]. A pragmatic view on both plan-driven and agile software development is not exclusive favouring one of the approaches, but rather locking where each approach is suitable. The choice of which approach to use should depend on the characteristics of a software development project at hand. In [1] B. Boehm and R. Turner describe five critical factors that describe the suitability of both approaches. These factors are size, criticality, dynamism, personnel and culture. They are used to assess the suitability of each development approach. More general, software practice reflects how a development approach and how a software process is working in a given real world situation and what actions are taken by developers in a project to follow the development approach or software process. This opens up for other factors than the five success factors mentioned above, to influence the actual practice. A framework to understand and describe the emergence of a working practice is presented by C. Slappendel [2] and used by Kautz et. al. [3] and Madsen et. al. [4] to understand the emergence of software practice. This framework consist of three perspectives: the individualist perspective, the structuralist perspective and the interactive process perspective. These perspectives open for factors such as previous experience, social context and the environment of a software development project. The emergence of software practice is thus influence by its context in such a way that the involved developers and stakeholders are engaging in activities, methods and techniques that based on their experience, beliefs and opinions will enable them to bring a project to a successful end and be satisfied personally. The environment of a software development project and the factors that influence the emergence of software practice are not stable but will most likely change during the course of development projects. A change in the environment of a development project has therefore implications for the software practice. The software practice that emerged in a given context to advance a development project to a successful end may not achieve this goal any more in a changed context. Responding to the changed environment makes it necessary to investigate
if the current software practice still is suitable and the right way to achieve the goals of a development project. Assuming that the environment of a development project is changing continuously the software practice has to be changed continuously, too. In other words, monitoring the environment of a software development project and evaluating the current software practice with respect to the environment is an ongoing activity. This evaluation will result in a recommendation to change the software practice when it is not suitable to achieve the projects goal under the changed environment. 2.2 Web application development To manage the development of web applications in a changing environment, it is necessary to understand both how web applications are developed and what internal change takes place in a web application during its lifetime. After web applications are launched initially, new versions are added in many cases continuously, with each new version adding new functionality. Web applications have therefore like other applications to manage requirements that are changing. At the same time, as a web application becomes more mature and fulfils the needs of it users, the development practices used to develop these requirements are also changing. This change has to be managed, too. The development practices used at any given time, reflects an applications environment and context. Discovering changes in this complex environment, that may influence the development practices, is not an easy task. A web application passes through some lifetime phases after its initial development and launch. This can be divided into two phases: an initial application phase launching the web application and getting attraction from potential users and a mature application phase when the application has a strong user base and seeks to fulfil their expectations. The transition between these phases is a gradual change over time, but still influences the development practices. Lifetime phases for a web application (1) Initial phase: When web applications are launched, there is a strong emphasise on time-to-market. A new web application needs to attract new customers with new and innovative functions and with a positive experience for the users. The overall goal is to get users to return to this web application and to use the services that it provides. In competition with other web applications it is important to be the first with a new functionality. This can sometimes be described as a rush-to-market approach, where presence is more important than quality. Deploying new and innovative functionality and getting the attention of potential users is perceived as an opportunity. Using a long time to develop new functionality and let the attention of potential users be drawn to competing applications is perceived as a risk. (2) Mature phase: When a web application becomes more mature, the focus is on keeping the existing users and try not to loose them to competing web applications. This is also reflected in the risk assessment at this time: to change the application too much, providing functionality that do not contribute to the users satisfaction
and thereby loosing existing users. At this time, understanding the needs of the users and providing functionality that fulfils their needs becomes an opportunity. Changing development practices Developing software with such an emphasise on time-to-market haves an impact on the development practices [5]. The development practises are informal and implementation oriented. Requirements are elicited and specified informally. Applications are not tested thoroughly, and many fixes are initiated by user reports. There is a lot of implicit knowledge, and the success of the application that is being developed is depending on the experience and general domain understanding of the developers. Early in the lifetime of an application, a lot of knowledge will be tacit with the involved stakeholders. Through simple communication it can be collected (see part 1 of figure 1), and this knowledge will be mostly qualitative as it represents the stakeholders opinion, belief and expert judgement. When it comes to manage the changing environment that web applications are operated within, it is important to evaluate the usefulness and appropriateness of the used development practices. It follows from the aforementioned that an informal requirement specification can be appropriate at an early stage of the application, whereas it is not appropriate in a later stage when we have a high risk of loosing costumers if the end-users are not satisfied. Thus, the development practices have to change too, together with the web application. 3 Related Work Web applications are developed in several contexts and environments. The purposes of web applications vary, and the lifetime of web applications vary, too. This is reflected on the development practises applied to develop them and by the tools and methods that are used developing them. The work on web application development processes is influenced by the variation in purpose and lifetime of web applications. In the last years, a number of development process for web application development have been proposed, where each process is addressing some characteristics that are important in a given context. A general model to assess and improve web processes is given in [6]. This paper divides web application development processes into two groups: the authoring process, concerned with the navigational structure of an web application, and the infrastructure process providing the computational infrastructure of a web applications. Developing a web application differs from traditional application development in a number of ways. One of the most prominent differences is the need to master the multidisciplinary nature of web applications. The navigational structure of a web application is an important part of the multidisciplinary side of web applications and needs special consideration. There are a number of web application processes that addresses the construction of the navigational structure. Web application processes such as UWE [7], NDT [8], The Araneus approach [9] and the Autoweb Development Process [10]. All of these processes are model-driven and depend on an intensive requirement specification. In application domains where time-to-market is important, most development teams
do not feel they have the time to specify the requirements as precise as is needed for these approaches to work. The other group of web application processes are supporting the development of business logic and other computational functionality. A common approach has been to use general development processes and to tailor them for the needs of web application development. Processes that are used in web application development are Agile Development [11], Extreme Programming [12], Scrum [13] and the OPEN Process [14]. There are also proposals of processes custom made for web application development such as WebHelix [15] and the Cognitive Web Based Software Development Process [16]. These processes are include issues that are special for web application development and that need special support, such as website management, content management, short development life-cycle times, multidisciplinary development teams and small development teams. None of these web application development processes are addressing the changing environment that web applications are developed in, and that influence the development practices that are used. This is not to say that these processes should not be used. They are addressing issues that are considered special for web application development and provides techniques and methodologies to manage these issues. However, when e-commerce web applications are developed with a strong emphasise on time-to-market, being aware of and managing the changing environment is crucial for the success of a web application. The subprocess proposed in this paper claims to be a valuable contribution to manage the changing environment of web applications and is intended to be used with other web development processes. 4 The changing environment of web application development Web applications are changing all the time, and this is dealt with more or less successful in many ways. This ever present change can be observed in many areas. Web applications are changing the contents they deliver to its users, and the graphical design and presentation of this content. Implementing changes requires the use of suitable techniques and methods. The technology that is used to implement the functionality of web applications is changing too. New technology has to be integrated with more proven technology, introducing compatibility problems and other problems arising from integrating several technologies. The end-users of web applications are also changing, both in their number and their expectation, and so is the risk that end-users are moving on to a competing web application. Other changes are related to the development practices applied to develop a web application and the trade-offs that are performed by choosing among these practices. The assumptions that these trade-offs are based on, are changing, and so is the knowledge that is available to make the decisions. Managing a web application over time calls for changing the development culture of a web application, so that it becomes suitable for the further development of the application [17].
1. 2. Tacit Explicit knowledge To knowledge High Tacit knowledge From Explicit knowledge Socialization Internalization Externalization Combination Customer Satisfaction Absent Requirements Wow-factor Surprise 1 2 Fully Implemented Implicit requirements Low Product Function Fig. 1. Part 1: Conversion of knowledge [18]. Part 2: Kano model 4.1 Change of knowledge When developing a software system, we will at any time have a certain degree of freedom to make decision and a certain amount of knowledge to base these decisions on. At the start of an applications development, the knowledge about the software system is limited, whereas the degree of freedom is high. With no knowledge available it is hard to take advantage of this freedom. In the end of the development, the degree of freedom is low, whereas there is a lot of knowledge about the system. The challenge is to gain as much knowledge as possible early in the development process, while the degree of freedom is still high. Even when the available knowledge is mostly tacit, it can still be exploited, and lessons can be learned from using it [19]. Over time, when more has been learned about the application under development, this knowledge can be refined. Exploiting tacit knowledge helps to take advantage of the degrees of freedom early in the development phase. Managing the collecting of knowledge and the change from tacit and informal knowledge towards more explicit and formal knowledge requires the use of suitable methods and tools. The tacit knowledge must be collected and analysed, which involves the conversion from tacit to explicit knowledge. A model for the conversion of knowledge is given by I. Nonaka [18] and is shown in part 1 of figure 1. This knowledge can then be organised, sorted, assessed and analysed (as in [20], [21], [5], and [19]), and decisions can be taken based on this analysis. 4.2 Change of opportunities and risks The opportunities and risks that a web application is facing depend on several factors. Among them are the lifetime phase of a web application [19], the competitive situation of a web application, and the end-users expectation.
Web applications are changing over time as they develop and mature. The lifetime of a web application can be divided into three phases: new application, intermediate application and mature application. There are opportunities and risks associated with each stage. A new application has to attract new end-users and to make visiting users return. This can be achieved by developing innovative and attractive functions. Short development cycles are important in the struggle with competing web applications. It is an opportunity for a web application to be the first one that offers functionality not offered by other web applications. Being late is a risk. The next phase is the intermediate phase with a base of returning end-users. The opportunities and risks are changing. Still, being innovative is important and an opportunity. But deploying new functionality too soon, at the cost of its quality, becomes a risk. In the last phase mature application keeping the end-users is important and loosing them is the risk. Changes to the web application are planned thoroughly. Satisfy the expectation of the end-users is the most opportunity. The end-users expectation to a web application and the user-experience it gives them, is another factor that influences the opportunities and risk of a web application. New features and functions can have the effect of giving the end-users a positive user-experience and being a competitive advantage. With time, this function will not be considered as a surprising function, and it will be something that the end-users expect. This change is illustrated by using the Kano model (see part 2 of figure 1), where surprises become requirements (1) and where requirements become implicit requirements (2). 5 Managing change in software application development Managing software applications in a changing environment is a necessary skill to develop a successful software application. Being able to manage this change means to achieve the goals and objectives that are defined for an application that is being developed, despite the changing environment. Managing change is an ongoing activity that will go on as long as the software application is developed and maintained. The challenge in managing change in web application development stems from the special characteristics that are found in web application development (see section 2). 5.1 A subprocess for managing the changing environment Managing the changing environment requires that a certain amount of planning is introduced into an otherwise ad hoc driven development effort. The aim is to introduce a small process that can be used together with other development methodologies (figure 2). The objectives for this subprocess are: To be used with other iterative development process, and with methods that are suitable in a situation and known to a project team.
To exploit the available knowledge, both qualitative and quantitative, to detect important changes in the development environment and to decide on the best action. To collect a base of knowledge for further development of a web application, adding new knowledge with every iteration. To enable learning from iteration to iteration, by evaluating how decisions where reached, and what results they yielded. Application objectives and vision Collect data Analyse data Make decision Implement and evaluate decision Lessons learned Knowledge base Fig. 2. Subprocess for managing changes in the development environment The subprocess has four steps that are described in detail below. For each step a goal is specified. How this goal can be reached depends on which life phase the applications is in and on the knowledge that is currently available. It is the developer s task to decide on what methods and tools are suitable to reach the described goal. 5.2 The subprocess step for step 1. Collect data The input to this step is the application vision and its objectives, and when this is not the first iteration experience from previous iterations and that is stored in the knowledge base. Goal: Create a shared understanding of the goals that have to be addressed by the current iteration and the decisions that have to be made, and collect knowledge that the next decisions can be based on. Activities: The activities in this step are Create a common understanding of the goals and objectives for the next iteration. What are the opportunities and risks in the current iteration? Identify and address issues that are important for the next iteration. What needs to be done to exploit the opportunities and to mitigate the risks?
Describe the available options to resolve the issues and collect knowledge that is needed to analyse the identified options. Collect knowledge about the applications environment such as the enduser expectation or other competing web applications, and that can have an effect on the identified options. The knowledge collected in this step can either be qualitative (a stakeholders opinion on the requirements) or quantitative (a measurement of the application performance). The activities in this step can be performed by applying several methods, such as affinity diagrams [22] or simple interviews with relevant stakeholders for qualitative data, and data from measurement initiatives that have been defined by using a measurement framework such as GQM [23], for quantitative data. 2. Analyse data This steps start with a list of issues that has to be resolved and possible options of implementing these issues. Goal: Assess the consequences of the available options, and the relationships between them and the web application s objectives and goals. Activities: To reach the goal of this step, the following activities has to be performed: Analyse the available options that were described in the previous step with respect to their consequences. Analyse the factors from the applications environment that have an effect on the available options, or that are influenced by them. Identify the relationships between the available options and the factors from the environment. When assessing the available options and the relationships with other factors, both opportunities and risks have to be identified. Other aspects that may be important to find a good decision, can be included, such as return of value. The assessment will depend on the available knowledge and the experience and beliefs of the involved stakeholders. If it should turn out during these activities that too little is known about important factors, the previous step can be repeated to collect more knowledge. The collected knowledge will be the starting point for the analysis in this step. If new knowledge is gained during this step, it will be added to collected knowledge. As the knowledge can be both in qualitative and quantitative form, methods for both types of knowledge are needed. There are several methods available to analyse qualitative data. The SWOT analysis [24] can identify strengths, weakness s, opportunities and threats in a simple way. The available options can be classified accordingly, and thereby the consequences can be shown. A similar method is Impact estimation tables [25], that assesses the available options according to some defined criteria. The advantage of this method is that any number of criteria can be defined. It is also a method that allows the combination of qualitative and quantitative data. Still another method to use is the Quality
Function Deployment method [26], that can be used to assess the requirement and option against some quality factors. These methods can be combined, as in [19], where a SWOT analysis is used together with a QFD-like matrix. When analysing quantitative data, there are several ways to estimate and predict the values of interest. 3. Decision making Based on the collected knowledge about the available options and the assessment of these options, a decision can be made. Goal: Find and decide on the option that best pursues the applications goal and best fulfils the stakeholders interests. Activities: The activities in this step are Prioritise the options that have been assessed in the previous step, according to the applications objectives or the stakeholder s interests. Resolve conflicts that may exists between the stakeholders and reach a common understanding for a decision. Document the background and motivation for the decision. This will help evaluating the decision and learning from it later in time. Making a decision that fulfils the interests of most stakeholders, is often not possible without performing a trade-off between the stakeholders. Especially when little knowledge about the application is explicit, and it is hard to predict the precise outcome of a decision, finding a decision that the stakeholders agree on will help to find a proper balance between the stakeholders interests. The options that are considered for a decision, are prioritised according to the degree in which they help pursue the application objectives and the stakeholders interests. In some cases, there could be a criteria such as return on value or costbenefit, whereas in other cases there is only an opinion from the stakeholders to which degree an option pursue the applications objectives and their interests. When qualitative information is involved, these criteria can also be expressed qualitative, as shown in [27]. When both quantitative and qualitative knowledge has to be combined, this can be done by either coding quantitative knowledge in a qualitative way or by coding qualitative knowledge in a quantitative way. Reaching a decision means also that conflicts has to be resolved. There are several ways this can be done. One way is to reach for a consensus oriented decision, where all stakeholders agree on the chosen decision. To reconcile all conflicts a Delphi like process can be used [28]. Another way is to vote for the decision and to let the majority of stakeholders get their will. This may also require reconciliation of conflicts between stakeholders, but the goal is to find a decision that the majority of stakeholders can agree on. 4. Implement and evaluate decision After the decision has been made and after it has been implemented, the outcome of the decision should be evaluated. Goal: Evaluate and analyse the outcome of the implemented decision with respect to the application s objective and the motivation for the decision. Deviations from what is expected and acceptable is analysed further, to find the root causes, potential improvements and lessons to learn for future use.
Activities: The activities in this step are Observe the outcome and the results of the implemented decision. Analyse and evaluate the outcome, with respect to the intention and motivation for the decision. Are the objectives met and is the outcome in line with the applications objectives as stated before the decision was made? In case the result is different from what is expected, an analysis should be conducted to investigate the root causes of the deviation. Document any lessons learned and new knowledge gained in this step for future use. Observing the outcome of a decision has to be done in a way that is suitable for the development team. A simple description with the stakeholders observations of the real outcome and a description of their expected outcome would do. This would be helpful for projects with no measurement instruments defined and where there is little explicit knowledge available. In other cases, when measurement instruments are already implemented, some aspects of the result could be measured and compared to the specified target. To analyse the root causes a simple Post-Mortem Analysis (PMA) [29] can be conducted. Based on the identified root causes, one can specify improvements actions. These are either improvements for the already taken and implemented decision whenever this is possible and relevant and improvements for future use and decisions. They are to be used in the next iteration or in later iterations. The lessons learned from the root cause analysis are stored in a repository, where they are available for future use. In the same way, new knowledge that has been gained through this iteration is stored in a knowledge base. 5.3 Knowledge base and Lessons learned For every iteration, new knowledge gained and the lessons that have been learned when making a decision should be kept for future use. Analysing the knowledge that a decision was based on and the outcome of the decision helps the development team identify where improvement is needed. Based on this analysis the development team will be able to improve its ability to chose the right action to achieve the desired outcome. Analysing the knowledge that a decision has been based on and the outcome of the decision identifies where more precise knowledge is needed. A measurement initiatives can be initiated based on this analysis. The knowledge gained in an iteration is stored in a way that is natural for the development team. There exists methods and tools to store knowledge and experience gained during an iteration. On such method is the Experience Factory [30], but the development team can also chose a simple approach, such as a text file, where knowledge and experience from a project so far are organised. At the end of each iteration, when the knowledge base is being updated, the iteration itself is evaluated. Are the development practises applied to develop the application in this iteration still appropriate?
5.4 Managing change by using the process The aims of the proposed subprocess are to be easy in use so that it can be used and integrated with other iterative development methodologies, to exploit both qualitative and quantitative information and combining them, and to support managing a changing environment. There are two necessary activities in managing change: Detecting change and deciding on the right response to meet the change. Basically, change comes in two ways. Change comes either evolutionary or revolutionary. The later is easy to observe, such as a introduction of new and innovative functionality or the introduction of new governmental regulation. The evolutionary change is, however, not always easy to detect. It can only be detected over time by comparing an assessment of a situation at two different times. The activities in the first two steps of the process Collect data and Analyse data are collecting and analysing data for every iteration. When assessing a certain situation, observations on the same situation from previous iterations is available and can be compared with the actual iteration. If there is a difference between the observations and if this difference represent a trend, a change is diagnosed. A method that can be used to detect a change is the gap analysis. The other activity is to decide on the right response to meet the change that has been detected. By coupling the decisions that have to be made to the applications vision and environment, change can be anticipated gradually for each iteration. The available options are assessed against the changing environment, and they are prioritised according to the degree in which they are appropriate in the given situation. 6 Conclusions and further work This paper has looked at the changing environment that web applications have to face, and proposed a subprocess to manage the changing environment. The aim of the subprocess is to create an awareness for the change, to detect how it influences a web application and to search for decisions that helps the development team to exploit the opportunities that comes with change and to set up barriers for the associated risks. The process helps the development team to use knowledge from different sources and to learn from decisions that have been made. References 1. Boehm, B., Turner, R.: Balancing Agility and Discipline. Addison Wesley Publishing Company, Inc. (2004) 2. Slappendel, C.: Perspectives on innovation in organizations. Organization Studies 17(1) (1996) 107 129 3. Kautz, K., Nielsen, P.A.: Understanding the implementation of software process improvement innovations in software organizations. Information Systems Journal 14(1) (2004) 3 22
4. Madsen, S., Kautz, K., Vidgen, R.T.: Method emergence in practice - influences and consequences. In: Proceedings of the 13th European Conference on Information Systems, Information Systems in a Rapidly Changing Economy, ECIS 2005, Regensburg, Germany, May 26-28, 2005. (2005) 5. Ziemer, S., Stålhane, T.: Web application development and quality - observations from interviews with companies in norway. In: Proceedings of Webist 2006. (2006) 6. Rodriguez, D., Harrison, R., Satpathy, M.: A generic model and tool support for assessing and improving web processes. In: Preceedings of the Eighth IEEE Symposium on Software Metrics (METRICS 02). (2002) 7. Koch, N., Kraus, A., Hennicker, R.: The authoring process of the uml-based web engineering approach. In: First International Workshop on Web-oriented Software Technology (IWWOST01). (2001) 8. Escalona, M., Mejias, M., Torres, J., Reina, A.: The ndt development process. In Lovelle, J.M.C., Rodrigues, B.M.G., Aguilar, L.J., Gayo, J., Ruiz, M., eds.: ICWE 2003: Proceedings of the 3th international conference on Web engineering. (2003) 9. Merialdo, P., Atzeni, P., Mecca, G.: Design and development of data-intensive web sites: The araneus approach. ACM Transactions on Internet Technology (TOIT) 3(1) (February 2003) 49 92 10. Fraternali, P., Paolini, P.: Model-driven development of web applications: the autoweb system. ACM Transactions on Information Systems (TOIS) 18(4) (2000) 323 382 11. McDonald, A., Welland, R.: Agile web engineering (awe) process. Technical report, Department of Computing Science, University of Glasgow (2001) 12. Maurer, F., Martel, S.: Extreme programming: Rapid development for web-based applications. IEEE Internet Computing Magazine 6(1) (2002) 86 90 13. Rising, L., Janoff, N.S.: The scrum software development process for small teams. IEEE Software 17(4) (July/August 2000) 26 32 14. Haire, B., Henderson-Sellers, B., Lowe, D.: Supporitng web development in the open process: Additinal tasks. In: Computer Software and Applications Conference, 2001. COMPSAC 2001. 25th Annual International. (2001) 383 389 15. Whitson, G.: Webhelix: another web engineering process. Journal of Computing Sciences in Colleges 21(5) (May 2006) 21 27 16. Kushwaha, D.S., Singh, R.K., Misra, A.K.: Cognitive web based software development process: towards a more reliable approach. SIGSOFT Software Engineering Notes 31(4) (2006) 1 6 17. Ramesh, B., Pries-Heje, J., Baskerville, R.: Internet software engineering: A different class of processes. Annals of Software Engineering 14 (2002) 196 195 18. Nonaka, I., Takeuchi, H.: The Knowledge Creating Company. Oxford University Press (1995) 19. Ziemer, S., Stålhane, T.: Trade-off s in web application development how to assess a trade-off opportunity. In: Proceedings Third International Conference on Web Information System and Technologies (WEBIST 2007), Barcelona, Spain, March 3-6, 2007. (2007) 20. Ziemer, S., Stålhane, T.: The use of trade-offs in the development of web applications. In Matera, M., Comai, S., eds.: Engineering Advanced Web Applications. Rinton Press (2004) 21. Ziemer, S., Stålhane, T., Sveen, M.: Trade-off analysis in web development. In: 3- WoSQ: Proceedings of the third workshop on Software quality, ACM Press (2005) 70 75 22. Straker, D.: A Toolbook for Quality Improvement and Problem Solving. Prentice Hall (1995)
23. Solingen, R.V., Berghout, E.: The Goal/Question/Metric Method: A Practical Guide for Quality Imprvement and Software Development. McGraw-Hill International (1999) 24. Hill, T., Westbrook, R.: Swot analysis: it s time for a product recall. Long Range Planning 30(1) (1997) 46 52 25. Gilb, T.: Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Butterworth- Heinemann Ltd (2005) 26. Akao, Y.: Quality Function Deployment. Productivity Press (1990) 27. Ziemer, S., Sampaio, P., Stålhane, T.: A decision modelling approach for analysing requirements configuration trade-offs in time-constrained web application development. In: Proceedings of SEKE 2006. (2006) 28. Linstone, H., Turoff, M.: The Delphi Method - Techniques and Applications. Addison Wesley Publishing Company, Inc. (1975) 29. Birk, A., Dingsoyr, T., Stalhane, T.: Postmortem: never leave a project without it. IEEE Software 19(3) (2002) 43 45 30. Basili, V., Caldiera, G., Romback, H.D.: Experience Factory. In: Encyclopedia of Software Engineering, Vol. 1. John Wiley Sons (1994) 476 496