Managing change in software development

Size: px
Start display at page:

Download "Managing change in software development"

Transcription

1 Managing change in software development Sven Ziemer Department of Computer and Information Science, Norwegian University of Science and Technology, NO-7491 Trondheim, Norway 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

2 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

3 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

4 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

5 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

6 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].

7 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.

8 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.

9 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?

10 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

11 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.

12 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?

13 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) Kautz, K., Nielsen, P.A.: Understanding the implementation of software process improvement innovations in software organizations. Information Systems Journal 14(1) (2004) 3 22

14 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) 5. Ziemer, S., Stålhane, T.: Web application development and quality - observations from interviews with companies in norway. In: Proceedings of Webist (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) Fraternali, P., Paolini, P.: Model-driven development of web applications: the autoweb system. ACM Transactions on Information Systems (TOIS) 18(4) (2000) 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) Rising, L., Janoff, N.S.: The scrum software development process for small teams. IEEE Software 17(4) (July/August 2000) Haire, B., Henderson-Sellers, B., Lowe, D.: Supporitng web development in the open process: Additinal tasks. In: Computer Software and Applications Conference, COMPSAC th Annual International. (2001) Whitson, G.: Webhelix: another web engineering process. Journal of Computing Sciences in Colleges 21(5) (May 2006) 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) Ramesh, B., Pries-Heje, J., Baskerville, R.: Internet software engineering: A different class of processes. Annals of Software Engineering 14 (2002) 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) 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) Straker, D.: A Toolbook for Quality Improvement and Problem Solving. Prentice Hall (1995)

15 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) 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) 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) Basili, V., Caldiera, G., Romback, H.D.: Experience Factory. In: Encyclopedia of Software Engineering, Vol. 1. John Wiley Sons (1994)

The use of Trade-offs in the development of Web Applications

The use of Trade-offs in the development of Web Applications The use of Trade-offs in the development of Web Applications Sven Ziemer and Tor Stålhane Department of Computer and Information Science Norwegian University of Technology and Science {svenz, stalhane}@idi.ntnu.no

More information

Trade-off Analysis in Web Development

Trade-off Analysis in Web Development Trade-off Analysis in Web Development Sven Ziemer Department of Computer and Information Science Sem Sælandsvei 7 9 NO-7491 Trondheim, Norway sven.ziemer@idi.ntnu.no An experiment on the use of QFD Tor

More information

Evaluation of Commercial Web Engineering Processes

Evaluation of Commercial Web Engineering Processes Evaluation of Commercial Web Engineering Processes Andrew McDonald and Ray Welland Department of Computing Science, University of Glasgow, Glasgow, Scotland. G12 8QQ. {andrew, ray}@dcs.gla.ac.uk, http://www.dcs.gla.ac.uk/

More information

Extending Agile Methods: Postmortem Reviews as Extended Feedback

Extending Agile Methods: Postmortem Reviews as Extended Feedback Extending Agile Methods: Postmortem Reviews as Extended Feedback Torgeir Dingsøyr, Geir Kjetil Hanssen SINTEF Telecom and Informatics, 7465 Trondheim, Norway (Torgeir.Dingsoyr Geir.K.Hanssen)@informatics.sintef.no

More information

Web Application Development Processes: Requirements, Demands and Challenges

Web Application Development Processes: Requirements, Demands and Challenges Web Application Development Processes: Requirements, Demands and Challenges THAMER AL-ROUSAN 1, BASEM HADIDI 2, SHADI ALJAWARNEH 3 1, 3 Faculty of Science and Information Technology, Isra University, Amman,

More information

Agile development of safety-critical software while meetings standards' requirements

Agile development of safety-critical software while meetings standards' requirements 1(37) Agile development of safety-critical software while meetings standards' requirements Matti Vuori, Tampere University of Technology 2011-11-04 Contents 1/2 A study in Ohjelmaturva 4 Tendency to be

More information

Measurable Software Quality Improvement through Innovative Software Inspection Technologies at Allianz Life Assurance

Measurable Software Quality Improvement through Innovative Software Inspection Technologies at Allianz Life Assurance Measurable Software Quality Improvement through Innovative Software Inspection Technologies at Allianz Life Assurance Bernd Freimut, Brigitte Klein, Oliver Laitenberger, Günther Ruhe Abstract The development

More information

Risk Knowledge Capture in the Riskit Method

Risk Knowledge Capture in the Riskit Method Risk Knowledge Capture in the Riskit Method Jyrki Kontio and Victor R. Basili jyrki.kontio@ntc.nokia.com / basili@cs.umd.edu University of Maryland Department of Computer Science A.V.Williams Building

More information

Knowledge Infrastructure for Project Management 1

Knowledge Infrastructure for Project Management 1 Knowledge Infrastructure for Project Management 1 Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur Kanpur, India 208016 Jalote@iitk.ac.in Abstract In any

More information

Implementing a Metrics Program MOUSE will help you

Implementing a Metrics Program MOUSE will help you Implementing a Metrics Program MOUSE will help you Ton Dekkers, Galorath tdekkers@galorath.com Just like an information system, a method, a technique, a tool or an approach is supporting the achievement

More information

MKS Integrity & CMMI. July, 2007

MKS Integrity & CMMI. July, 2007 & CMMI July, 2007 Why the drive for CMMI? Missed commitments Spiralling costs Late delivery to the market Last minute crunches Inadequate management visibility Too many surprises Quality problems Customer

More information

V. Phani Krishna et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 2 (6), 2011, 2915-2919

V. Phani Krishna et al, / (IJCSIT) International Journal of Computer Science and Information Technologies, Vol. 2 (6), 2011, 2915-2919 Software Quality Assurance in CMM and XP- A Comparative Study CH.V. Phani Krishna and Dr. K.Rajasekhara Rao CSE Department, KL University, Guntur dt., India. Abstract Software Quality Assurance is a planned

More information

Transactions on Information and Communications Technologies vol 11, 1995 WIT Press, www.witpress.com, ISSN 1743-3517

Transactions on Information and Communications Technologies vol 11, 1995 WIT Press, www.witpress.com, ISSN 1743-3517 Impact analysis of process change proposals* M. Host and C. Wohlin Department of Communication Systems, Lund University, PO Box 118, S-221 00 Lund, Sweden Abstract Before software processes are changed

More information

How To Understand The Limitations Of An Agile Software Development

How To Understand The Limitations Of An Agile Software Development A Cynical View on Agile Software Development from the Perspective of a new Small-Scale Software Industry Apoorva Mishra Computer Science & Engineering C.S.I.T, Durg, India Deepty Dubey Computer Science

More information

Retrofitting Security into a Web-Based Information System

Retrofitting Security into a Web-Based Information System Retrofitting Security into a Web-Based Information System David Bettencourt da Cruz, Bernhard Rumpe, Guido Wimmel Software & Systems Engineering, Technische Universität München 85748 Munich/Garching, Germany

More information

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

Sven Ziemer. Trade-offs for web application development: understanding and improving current industrial practices Sven Ziemer Doctoral theses at NTNU, 2009:02 Sven Ziemer Trade-offs for web application development: understanding and improving current industrial practices ISBN 978-82-471-1372-1 (printed ver.) ISBN

More information

The profile of your work on an Agile project will be very different. Agile projects have several things in common:

The profile of your work on an Agile project will be very different. Agile projects have several things in common: The Agile Business Analyst IT s all about being Agile? You re working as a Business Analyst in a traditional project environment, specifying the requirements for IT Developers to build. Suddenly everyone

More information

Investigation of Adherence Degree of Agile Requirements Engineering Practices in Non-Agile Software Development Organizations

Investigation of Adherence Degree of Agile Requirements Engineering Practices in Non-Agile Software Development Organizations Investigation of Adherence Degree of Agile Requirements Engineering Practices in Non-Agile Software Development Organizations Mennatallah H. Ibrahim Department of Computers and Information Sciences Institute

More information

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3)

PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) PORTFOLIO, PROGRAMME & PROJECT MANAGEMENT MATURITY MODEL (P3M3) 1st February 2006 Version 1.0 1 P3M3 Version 1.0 The OGC logo is a Registered Trade Mark of the Office of Government Commerce This is a Value

More information

Journal of Internet Banking and Commerce

Journal of Internet Banking and Commerce Journal of Internet Banking and Commerce An open access Internet journal (http://www.arraydev.com/commerce/jibc/) Journal of Internet Banking and Commerce, August 2011, vol. 16, no.2 (http://www.arraydev.com/commerce/jibc/)

More information

Success Factors of Agile Software Development

Success Factors of Agile Software Development Success Factors of Agile Software Development Subhas C. Misra, Vinod Kumar, and Uma Kumar Carleton University, Ottawa, Canada Abstract Agile software development methodologies have recently gained widespread

More information

CMMI KEY PROCESS AREAS

CMMI KEY PROCESS AREAS CMMI KEY PROCESS AREAS http://www.tutorialspoint.com/cmmi/cmmi-process-areas.htm Copyright tutorialspoint.com A Process Area is a cluster of related practices in an area that, when implemented collectively,

More information

A GOAL/QUESTION/METRIC RESEARCH PROPOSAL TO MONITOR USER INVOLVEMENT AND PARTICIPATION IN ERP IMPLEMENTATION PROJECTS

A GOAL/QUESTION/METRIC RESEARCH PROPOSAL TO MONITOR USER INVOLVEMENT AND PARTICIPATION IN ERP IMPLEMENTATION PROJECTS A GOAL/QUESTION/METRIC RESEARCH PROPOSAL TO MONITOR USER INVOLVEMENT AND PARTICIPATION IN ERP IMPLEMENTATION PROJECTS Abstract José Manuel Esteves Departament de Llenguatges i Sistemes Informàtics Universitat

More information

P3M3 Portfolio Management Self-Assessment

P3M3 Portfolio Management Self-Assessment Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire P3M3 Portfolio Management Self-Assessment P3M3 is a registered trade mark of AXELOS Limited Contents Introduction

More information

ISO, CMMI and PMBOK Risk Management: a Comparative Analysis

ISO, CMMI and PMBOK Risk Management: a Comparative Analysis ISO, CMMI and PMBOK Risk Management: a Comparative Analysis Cristine Martins Gomes de Gusmão Federal University of Pernambuco / Informatics Center Hermano Perrelli de Moura Federal University of Pernambuco

More information

CMMI STANDARDS IN SOFTWARE DEVELOPING PROCESS

CMMI STANDARDS IN SOFTWARE DEVELOPING PROCESS CMMI STANDARDS IN SOFTWARE DEVELOPING PROCESS 1 2 C. SenthilMurugan, Dr. S. Prakasam. PhD Scholar Asst., Professor 1,2 Dept of Computer Science & Application, SCSVMV University, Kanchipuram 1 Dept of MCA,

More information

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc.

Your Software Quality is Our Business. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. INDEPENDENT VERIFICATION AND VALIDATION (IV&V) WHITE PAPER Prepared by Adnet, Inc. February 2013 1 Executive Summary Adnet is pleased to provide this white paper, describing our approach to performing

More information

ReBEC: a Method for Capturing Experience during Software Development Projects

ReBEC: a Method for Capturing Experience during Software Development Projects ReBEC: a Method for Capturing Experience during Software Development Projects Gerardo Matturro 1, Andrés Silva 2 1 Universidad ORT Uruguay, Cuareim 1451, 11200 Montevideo, Uruguay matturro@uni.ort.edu.uy

More information

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK IBM Software Group Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK Jean-Louis Maréchaux Software IT Specialist IBM Rational

More information

Plan-Driven Methodologies

Plan-Driven Methodologies Plan-Driven Methodologies The traditional way to develop software Based on system engineering and quality disciplines (process improvement) Standards developed from DoD & industry to make process fit a

More information

Universiteit Leiden. ICT in Business. Leiden Institute of Advanced Computer Science (LIACS) Capability Maturity Model for Software Usage

Universiteit Leiden. ICT in Business. Leiden Institute of Advanced Computer Science (LIACS) Capability Maturity Model for Software Usage Universiteit Leiden ICT in Business Capability Maturity Model for Software Usage Name: Yunwei Huang Student-no: s1101005 Date: 16/06/2014 1st supervisor: Dr. Luuk Groenewegen 2nd supervisor: Dr. Nelleke

More information

C. Wohlin, "Is Prior Knowledge of a Programming Language Important for Software Quality?", Proceedings 1st International Symposium on Empirical

C. Wohlin, Is Prior Knowledge of a Programming Language Important for Software Quality?, Proceedings 1st International Symposium on Empirical C. Wohlin, "Is Prior Knowledge of a Programming Language Important for Software Quality?", Proceedings 1st International Symposium on Empirical Software Engineering, pp. 27-36, Nara, Japan, October 2002.

More information

ADAPTING THE SOFTWARE ENGINEERING PROCESS TO WEB ENGINEERING PROCESS

ADAPTING THE SOFTWARE ENGINEERING PROCESS TO WEB ENGINEERING PROCESS ADAPTING THE SOFTWARE ENGINEERING PROCESS TO WEB ENGINEERING PROCESS Sandeep Kumar Satyaveer Sangwan Department of Information Technology, M. M. Engineering College, M. M. University, Mullana-Ambala (Haryana),

More information

Using Reflective Guides to Capture Software Projects Experience

Using Reflective Guides to Capture Software Projects Experience 202 Int'l Conf. Information and Knowledge Engineering IKE'10 Using Reflective Guides to Capture Software Projects Experience Gerardo Matturro 1, Andres Silva 2 1 Departamento de Ingeniería de Software,

More information

Software Quality Development and Assurance in RUP, MSF and XP - A Comparative Study

Software Quality Development and Assurance in RUP, MSF and XP - A Comparative Study Software Quality Development and Assurance in RUP, MSF and XP - A Comparative Study Wolfgang Zuser Vienna University of Technology wolfgang.zuser@inso.tuwien.ac.at Stefan Heil Capgemini Consulting Austria

More information

TDWI strives to provide course books that are content-rich and that serve as useful reference documents after a class has ended.

TDWI strives to provide course books that are content-rich and that serve as useful reference documents after a class has ended. Previews of TDWI course books offer an opportunity to see the quality of our material and help you to select the courses that best fit your needs. The previews cannot be printed. TDWI strives to provide

More information

PMI Risk Management Professional (PMI-RMP ) - Practice Standard and Certification Overview

PMI Risk Management Professional (PMI-RMP ) - Practice Standard and Certification Overview PMI Risk Management Professional (PMI-RMP ) - Practice Standard and Certification Overview Sante Torino PMI-RMP, IPMA Level B Head of Risk Management Major Programmes, Selex ES / Land&Naval Systems Division

More information

Process Improvement. Objectives

Process Improvement. Objectives Process Improvement Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 1 Objectives To explain the principles of software process improvement To explain how software process factors

More information

Keywords document, agile documentation, documentation, Techno functional expert, Team Collaboration, document selection;

Keywords document, agile documentation, documentation, Techno functional expert, Team Collaboration, document selection; Volume 4, Issue 4, April 2014 ISSN: 2277 128X International Journal of Advanced Research in Computer Science and Software Engineering Research Paper Available online at: www.ijarcsse.com A Document Driven

More information

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment

Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire. P3M3 Project Management Self-Assessment Procurement Programmes & Projects P3M3 v2.1 Self-Assessment Instructions and Questionnaire P3M3 Project Management Self-Assessment Contents Introduction 3 User Guidance 4 P3M3 Self-Assessment Questionnaire

More information

Mahmoud Khraiwesh Faculty of Science and Information Technology Zarqa University Zarqa - Jordan mahmoud@zpu.edu.jo

Mahmoud Khraiwesh Faculty of Science and Information Technology Zarqa University Zarqa - Jordan mahmoud@zpu.edu.jo World of Computer Science and Information Technology Journal (WCSIT) ISSN: 2221-0741 Vol. 1, No. 2, 26-33, 2011 Validation Measures in CMMI Mahmoud Khraiwesh Faculty of Science and Information Technology

More information

Corresponding Author email: javeri_mit@yahoo.com

Corresponding Author email: javeri_mit@yahoo.com International Research Journal of Applied and Basic Sciences 2013 Available online at www.irjabs.com ISSN 2251838X / Vol, 5 (11): 14381445 Science Explorer Publications Presenting a model for the deployment

More information

Evaluation and Integration of Risk Management in CMMI and ISO/IEC 15504

Evaluation and Integration of Risk Management in CMMI and ISO/IEC 15504 Evaluation and Integration of Risk Management in CMMI and ISO/IEC 15504 Dipak Surie, Email : ens03dse@cs.umu.se Computing Science Department Umea University, Umea, Sweden Abstract. During software development,

More information

An integrated life cycle quality model for general public market software products

An integrated life cycle quality model for general public market software products An integrated life cycle quality model for general public market software products Witold Suryn 1, Alain Abran 2, Claude Laporte 3 1 Département de génie électrique, École de technologie supérieure 1100,

More information

HYBRID WEB ENGINEERING PROCESS MODEL FOR THE DEVELOPMENT OF LARGE SCALE WEB APPLICATIONS

HYBRID WEB ENGINEERING PROCESS MODEL FOR THE DEVELOPMENT OF LARGE SCALE WEB APPLICATIONS HYBRID WEB ENGINEERING PROCESS MODEL FOR THE DEVELOPMENT OF LARGE SCALE WEB APPLICATIONS OMAIMA N. A. AL-ALLAF Department of CIS, Faculty of Sciences and Information Technology, AL-Zaytoonah University

More information

SOFTWARE QUALITY MODELS: A COMPARATIVE STUDY

SOFTWARE QUALITY MODELS: A COMPARATIVE STUDY SOFTWARE QUALITY MODELS: A COMPARATIVE STUDY Mrs. Manisha L. Waghmode Assistant Professor Bharati Vidyapeeth Deemed University, Institute of Management and Rural Development Administration, Sangli Dr.

More information

6. Software Lifecycle Models. A software lifecycle model is a standardised format for planning organising, and running a new development project.

6. Software Lifecycle Models. A software lifecycle model is a standardised format for planning organising, and running a new development project. 6. Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and running a new development project. Hundreds of different kinds of models are known and used.

More information

Life Cycle Models, CMMI, Lean, Six Sigma Why use them?

Life Cycle Models, CMMI, Lean, Six Sigma Why use them? Life Cycle Models, CMMI, Lean, Six Sigma Why use them? John Walz IEEE Computer Society, VP for Standards QuEST Forum Best Practices Conference Track 3 What, Where, How & Why Monday, 24-Sep-07, 4:30 5:30

More information

Software Quality and Assurance in Waterfall model and XP - A Comparative Study

Software Quality and Assurance in Waterfall model and XP - A Comparative Study Software Quality and Assurance in Waterfall model and XP - A Comparative Study Dr. Sana a Jawdat Khalaf Sana_j_11@hotmail.com Dr. Mohamed Noor Al-Jedaiah m_aljedaiah@ammanu.edu.jo Abstract: -Dealing with

More information

A Contrast and Comparison of Modern Software Process Models

A Contrast and Comparison of Modern Software Process Models A Contrast and Comparison of Modern Software Process s Pankaj Vohra Computer Science & Engineering Department Thapar University, Patiala Ashima Singh Computer Science & Engineering Department Thapar University,

More information

Benefits Realization from IS & IT, and Change Management of roles and the working practices of individuals and teams.

Benefits Realization from IS & IT, and Change Management of roles and the working practices of individuals and teams. : Delivering Value from IS & IT Investments John Ward and Elizabeth Daniel John Wiley & Son Ltd ISBN: 9780470094631, 399 pages Theme of the Book This book explores a process and practical tools and frameworks

More information

Leveraging CMMI framework for Engineering Services

Leveraging CMMI framework for Engineering Services Leveraging CMMI framework for Engineering Services Regu Ayyaswamy, Mala Murugappan Tata Consultancy Services Ltd. Introduction In response to Global market demand, several OEMs adopt Global Engineering

More information

PHASE 8: IMPLEMENTATION PHASE

PHASE 8: IMPLEMENTATION PHASE PHASE 8: IMPLEMENTATION PHASE The Implementation Phase has one key activity: deploying the new system in its target environment. Supporting actions include training end-users and preparing to turn the

More information

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction

Lecture Slides for Managing and Leading Software Projects. Chapter 1: Introduction Lecture Slides for Managing and Leading Software Projects Chapter 1: Introduction developed by Richard E. (Dick) Fairley, Ph.D. to accompany the text Managing and Leading Software Projects published by

More information

A Framework for Integrating Software Usability into Software Development Process

A Framework for Integrating Software Usability into Software Development Process A Framework for Integrating Software Usability into Software Development Process Hayat Dino AFRICOM Technologies, Addis Ababa, Ethiopia hayudb@gmail.com Rahel Bekele School of Information Science, Addis

More information

Effects of Knowledge Management in Small-Sized Software Organizations

Effects of Knowledge Management in Small-Sized Software Organizations Effects of Knowledge Management in Small-Sized Software Organizations Gajendra Patil 1, Dr. G R Bamnote 2 Research Scholar, Dr K N Modi University, Newai, Rajasthan, India 1 Professor & Head, Prof Ram

More information

Introduction to Software Engineering

Introduction to Software Engineering CS1Ah Lecture Note 7 Introduction to Software Engineering In this note we provide an overview of Software Engineering. The presentation in this lecture is intended to map out much of what we will study

More information

MDE Adoption in Industry: Challenges and Success Criteria

MDE Adoption in Industry: Challenges and Success Criteria MDE Adoption in Industry: Challenges and Success Criteria Parastoo Mohagheghi 1, Miguel A. Fernandez 2, Juan A. Martell 2, Mathias Fritzsche 3 and Wasif Gilani 3 1 SINTEF, P.O.Box 124-Blindern, N-0314

More information

METRICS DRIVEN CONTINUAL SERVICE IMPROVEMENT USING AGILE CONCEPTS

METRICS DRIVEN CONTINUAL SERVICE IMPROVEMENT USING AGILE CONCEPTS METRICS DRIVEN CONTINUAL SERVICE IMPROVEMENT USING AGILE CONCEPTS John Osteen B Cognizant Business Consulting Process Quality Consulting Cognizant Technology Solutions, Chennai, India john.b@cognizant.com

More information

STAGE 1 COMPETENCY STANDARD FOR PROFESSIONAL ENGINEER

STAGE 1 COMPETENCY STANDARD FOR PROFESSIONAL ENGINEER STAGE 1 STANDARD FOR PROFESSIONAL ENGINEER ROLE DESCRIPTION - THE MATURE, PROFESSIONAL ENGINEER The following characterises the senior practice role that the mature, Professional Engineer may be expected

More information

Quality Management of Software and Systems: Continuous Improvement Approaches

Quality Management of Software and Systems: Continuous Improvement Approaches Quality Management of Software and Systems: Continuous Improvement Approaches Contents Quality Improvement Paradigm (QIP) Experience Factory (EF) Goal Question Metric (GQM) GQM + Strategies TQM Definition

More information

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW

TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW Year 2014, Vol. 1, issue 1, pp. 49-56 Available online at: http://journal.iecuniversity.com TRADITIONAL VS MODERN SOFTWARE ENGINEERING MODELS: A REVIEW Singh RANDEEP a*, Rathee AMIT b a* Department of

More information

CMMI: Specific Goals and Practices

CMMI: Specific Goals and Practices Software Engineering for Outsourced & Offshore Development CMMI: Specific Goals and Practices PeterKolb Software Engineering CMMI Process Areas for R&D Projects Slide 2 Content Management in Projects Project

More information

Project Risk Management

Project Risk Management Project Risk Management Study Notes PMI, PMP, CAPM, PMBOK, PM Network and the PMI Registered Education Provider logo are registered marks of the Project Management Institute, Inc. Points to Note Risk Management

More information

How To Scale Agile Development With Knowledge Management

How To Scale Agile Development With Knowledge Management Managing Knowledge in Development of Agile Software Mohammed Abdul Bari Department of Computer Science, College of Science & Arts University of Al-Kharj Wadi Al-Dawasir-11991, Kingdom of Saudi Arabia Dr.

More information

A Report on The Capability Maturity Model

A Report on The Capability Maturity Model A Report on The Capability Maturity Model Hakan Bayraksan hxb07u 29 November 2009 G53QAT Table of Contents Introduction...2 The evolution of CMMI...3 CMM... 3 CMMI... 3 The definition of CMMI... 4 Level

More information

SERENITY Pattern-based Software Development Life-Cycle

SERENITY Pattern-based Software Development Life-Cycle SERENITY Pattern-based Software Development Life-Cycle Francisco Sanchez-Cid, Antonio Maña Computer Science Department University of Malaga. Spain {cid, amg}@lcc.uma.es Abstract Most of current methodologies

More information

CS4507 Advanced Software Engineering

CS4507 Advanced Software Engineering CS4507 Advanced Software Engineering Lectures 2 & 3: Software Development Lifecycle Models A O Riordan, 2015 Some diagrams from Sommerville, some notes from Maciaszek/Liong Lifecycle Model Software development

More information

GQM + Strategies in a Nutshell

GQM + Strategies in a Nutshell GQM + trategies in a Nutshell 2 Data is like garbage. You had better know what you are going to do with it before you collect it. Unknown author This chapter introduces the GQM + trategies approach for

More information

CREATING A LEAN BUSINESS SYSTEM

CREATING A LEAN BUSINESS SYSTEM CREATING A LEAN BUSINESS SYSTEM This white paper provides an overview of The Lean Business Model how it was developed and how it can be used by enterprises that have decided to embark on a journey to create

More information

CMMI - The AGILE Way By Hitesh Sanghavi

CMMI - The AGILE Way By Hitesh Sanghavi CMMI - The AGILE Way By Hitesh Sanghavi 1 The Maturity Levels 5 Focus on process improvement Optimizing 3 4 2 Process measured and controlled Process characterized for the organization and is proactive

More information

Hathaichanok Suwanjang and Nakornthip Prompoon

Hathaichanok Suwanjang and Nakornthip Prompoon Framework for Developing a Software Cost Estimation Model for Software Based on a Relational Matrix of Project Profile and Software Cost Using an Analogy Estimation Method Hathaichanok Suwanjang and Nakornthip

More information

Agile Requirements Definition for Software Improvement and Maintenance in Open Source Software Development

Agile Requirements Definition for Software Improvement and Maintenance in Open Source Software Development Agile Requirements Definition for Software Improvement and Maintenance in Open Source Software Development Stefan Dietze Fraunhofer Institute for Software and Systems Engineering (ISST), Mollstr. 1, 10178

More information

The Role of CM in Agile Development of Safety-Critical Software

The Role of CM in Agile Development of Safety-Critical Software The Role of CM in Agile Development of Safety-Critical Software Tor Stålhane1, Thor Myklebust 2 1 Norwegian University of Science and Technology, N-7491, Trondheim, Norway 2 SINTEF ICT, Strindveien 2,

More information

An Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications

An Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications An Aspect-Oriented Product Line Framework to Support the Development of Software Product Lines of Web Applications Germán Harvey Alférez Salinas Department of Computer Information Systems, Mission College,

More information

707.009 Foundations of Knowledge Management Organizational Knowledge Repositories

707.009 Foundations of Knowledge Management Organizational Knowledge Repositories 707.009 Foundations of Knowledge Management Organizational Knowledge Repositories Markus Strohmaier Univ. Ass. / Assistant Professor Knowledge Management Institute Graz University of Technology, Austria

More information

Partnering for Project Success: Project Manager and Business Analyst Collaboration

Partnering for Project Success: Project Manager and Business Analyst Collaboration Partnering for Project Success: Project Manager and Business Analyst Collaboration By Barbara Carkenord, CBAP, Chris Cartwright, PMP, Robin Grace, CBAP, Larry Goldsmith, PMP, Elizabeth Larson, PMP, CBAP,

More information

Agile-Fall Process Flow Model A Right Candidate for Implementation in Software Development and Testing Processes for Software Organizations

Agile-Fall Process Flow Model A Right Candidate for Implementation in Software Development and Testing Processes for Software Organizations www.ijcsi.org 457 Agile-Fall Process Flow Model A Right Candidate for Implementation in Software Development and Testing Processes for Software Organizations Prakash.V SenthilAnand.N Bhavani.R Assistant

More information

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material,

More information

A case study of software procurement strategies in Sudanese organizations Key words Abstract INTRODUCTION

A case study of software procurement strategies in Sudanese organizations Key words Abstract INTRODUCTION A case study of software procurement strategies in Sudanese organizations Mohamed Abbas, Hisham Abu Shama and Gada Kadoda*** Department of Computer Science, University of Khartoum, P.O. Box 321, Khartoum,

More information

Qualipso Project: Quality Recommendations for FLOSS development processes

Qualipso Project: Quality Recommendations for FLOSS development processes UNIVERSIDADE DE SÃO PAULO Qualipso Project: Quality Recommendations for FLOSS development processes A perspective based on trustworthy elements Viviane Malheiros, Erika Höhn, José Carlos Maldonado RT-335

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

Salion s Experience with a Reactive Software Product Line Approach

Salion s Experience with a Reactive Software Product Line Approach Salion s Experience with a Reactive Software Product Line Approach Ross Buhrdorf Dale Churchett Salion, Inc., 720 Brazos St., Ste. 700 Austin TX 78701 USA ross.buhrdorf@salion.com dale.churchett@salion.com

More information

An Approach to Proactive Risk Classification

An Approach to Proactive Risk Classification An Approach to Proactive Risk Classification M.S. Rojabanu 1, Dr. K. Alagarsamy 2 1 Research Scholar, Madurai Kamaraj Universtiy, Madurai,India. 2 Associate Professor, Computer Centre, Madurai Kamaraj

More information

Family Evaluation Framework overview & introduction

Family Evaluation Framework overview & introduction A Family Evaluation Framework overview & introduction P B Frank van der Linden O Partner: Philips Medical Systems Veenpluis 4-6 5684 PC Best, the Netherlands Date: 29 August, 2005 Number: PH-0503-01 Version:

More information

Measurement repository for Scrum-based software development process

Measurement repository for Scrum-based software development process Measurement repository for Scrum-based software development process VILJAN MAHNIC, NATASA ZABKAR Faculty of Computer and Information Science University of Ljubljana Trzaska 25, SI-1000 Ljubljana SLOVENIA

More information

SecSDM: A Model for Integrating Security into the Software Development Life Cycle

SecSDM: A Model for Integrating Security into the Software Development Life Cycle SecSDM: A Model for Integrating Security into the Software Development Life Cycle Lynn Futcher, Rossouw von Solms Centre for Information Security Studies, Nelson Mandela Metropolitan University, Port Elizabeth,

More information

Knowledge Management in Software Companies An Appraisal

Knowledge Management in Software Companies An Appraisal Knowledge Management in Software Companies An Appraisal B. Gopalkrishna, Lewlyn L. R. Rodrigues, P. K. Poornima, and Shivanshu Manchanda Abstract The present study involved evaluation of state of knowledge

More information

How To Test For Elulla

How To Test For Elulla EQUELLA Whitepaper Performance Testing Carl Hoffmann Senior Technical Consultant Contents 1 EQUELLA Performance Testing 3 1.1 Introduction 3 1.2 Overview of performance testing 3 2 Why do performance testing?

More information

Requirements Engineering

Requirements Engineering Murali Chemuturi Requirements Engineering and Management for Software Development Projects Foreword by Tom Gilb ^ Springer Contents 1 Introduction to Requirements Engineering and Management... 1 1.1 What

More information

Capability Maturity Model Integration (CMMI SM ) Fundamentals

Capability Maturity Model Integration (CMMI SM ) Fundamentals Capability Maturity Model Integration (CMMI SM ) Fundamentals Capability Maturity Model Integration and CMMI are are service marks of Carnegie Mellon University 2008, GRafP Technologies inc. 1 What is

More information

Chapter 3 Chapter 3 Service-Oriented Computing and SOA Lecture Note

Chapter 3 Chapter 3 Service-Oriented Computing and SOA Lecture Note Chapter 3 Chapter 3 Service-Oriented Computing and SOA Lecture Note Text book of CPET 545 Service-Oriented Architecture and Enterprise Application: SOA Principles of Service Design, by Thomas Erl, ISBN

More information

Agile Web Engineering (AWE) Process

Agile Web Engineering (AWE) Process Agile Web Engineering (AWE) Process Andrew McDonald and Ray Welland Department of Computing Science, University of Glasgow, Glasgow, Scotland. G12 8QQ Abstract 02 December 2001 This document describes

More information

Development and Integration Issues about Software Engineering, Systems Engineering and Project Management Processes

Development and Integration Issues about Software Engineering, Systems Engineering and Project Management Processes Software Process Improvement 98, Monte Carlo, December 1998. 1 Development and Integration Issues about Software Engineering, s Engineering and Project Management Processes Claude Y. Laporte Oerlikon Aerospace

More information

Software Quality Management

Software Quality Management Software Lecture 9 Software Engineering CUGS Spring 2011 Kristian Sandahl Department of Computer and Information Science Linköping University, Sweden A Software Life-cycle Model Which part will we talk

More information

RISK MANAGEMENT IN DISTRIBUTED SOFTWARE DEVELOPMENT: A PROCESS INTEGRATION PROPOSAL i

RISK MANAGEMENT IN DISTRIBUTED SOFTWARE DEVELOPMENT: A PROCESS INTEGRATION PROPOSAL i 01 RISK MANAGEMENT IN DISTRIBUTED SOFTWARE DEVELOPMENT: A PROCESS INTEGRATION PROPOSAL i Rafael Prikladnicki School of Computer Science, PUCRS, rafael@inf.pucrs.br Marcelo Hideki Yamaguti School of Computer

More information

Software Requirements, Third Edition

Software Requirements, Third Edition j Microsoft Software Requirements, Third Edition Karl Wiegers and Joy Beatty Contents Introduction Acknowledgments xxv xxxi PART I SOFTWARE REQUIREMENTS: WHAT, WHY, AND WHO Chapter 1 The essential software

More information

A Methodology for Software Process Improvement Roadmaps for Regulated Domains Example with ISO 62366

A Methodology for Software Process Improvement Roadmaps for Regulated Domains Example with ISO 62366 A Methodology for Software Process Improvement Roadmaps for Regulated Domains Example with ISO 62366 Derek Flood, Fergal Mc Caffery, Valentine Casey, Gilbert Regan Dundalk Institute of Technology, {Derek.flood,

More information

OPTIMUS SBR. Optimizing Results with Business Intelligence Governance CHOICE TOOLS. PRECISION AIM. BOLD ATTITUDE.

OPTIMUS SBR. Optimizing Results with Business Intelligence Governance CHOICE TOOLS. PRECISION AIM. BOLD ATTITUDE. OPTIMUS SBR CHOICE TOOLS. PRECISION AIM. BOLD ATTITUDE. Optimizing Results with Business Intelligence Governance This paper investigates the importance of establishing a robust Business Intelligence (BI)

More information

MTAT.03.243 Software Engineering Management

MTAT.03.243 Software Engineering Management MTAT.03.243 Software Engineering Management Lecture 17: Other SPI Frameworks and QM Systems Dietmar Pfahl Spring 2014 email: dietmar.pfahl@ut.ee Structure of Lecture 17 Other SPI Frameworks People CMM

More information