Today little is known about what tools software companies are using to support their Agile methods and whether they are satisfied or dissatisfied with them. This is due to lack of objective surveys on the subject. The surveys that have been conducted so far are of a subjective nature and have mostly been performed by tool vendors. They are very limited in number and focus mainly on company structure and adherence to a specific Agile method rather than on tool usage and needs. For this reason many companies have difficulties to choose appropriate tools to support their Agile process. One such company is the Swedish telecommunications giant Ericsson. To account for this lack of data Ericsson commissioned us to conduct an independent survey focusing on the tool usage and needs as experienced by the Agile software community today. In this paper we report on the results of our survey. The survey covers 121 responses from 120 different companies coming from 35 different countries. Our results show that the most satisfactory tool aspect is ease of use whereas the least satisfactory one is lack of integration with other systems. Finally our results provide a list of features that are most desired by the software companies today.

The purpose of writing this Three Year Vision paper is threefold. Firstly, it briefly recaps theprogress Semat has made thus far; secondly, it lays out the future directions for people working actively withinthe Semat community; thirdly, it provides the background for seeking funding support from agencies, such asthe European Community and the like. Funding support is necessary to sustain the ongoing activities ofSemat and its growth into a broader community effort, as most people working within Semat are volunteers.As such, the paper may be both too much and too little for the wider supporter base. However, we intend tomake our work fully transparent, hence, we publish it widely. We seek feedback and comments from supporters and signatories in order to improve the vision. In this context, other companion papers are being writtento better address the specific needs for the practitioners, the industry and the academia.

Software engineering is gravely hampered by immature practices. Specific problems include: The prevalence of fads more typical of the fashion industry than an engineering discipline; a huge number of methods and method variants, with differences little understood and artificially magnified; the lack of credible experimental evaluation and validation; and the split between industry practice and academic research.

Recently, developers' testing process has received more recognition. Despite this, we have still no insight into its status within the industry. In this paper, we study the status of developers' testing process at Nomadic Software AB. Our results show that the process is not uniformly executed. The company suffers from lack of control over the methods used, lack of formal requirements communication, lack of static testing practice and lack of testing process documentation.

Even if recent methodologies bring more recognition to developers’ testing process, we still have little insightinto its status within the industry. In this paper, we study the status of developers’ testing process atNomadic Software. Our results show that the process is not uniformly executed. The company suffers fromlack of control over the methods used, lack of formal communication on requirements, lack of static testingpractice, and lack of testing process documentation.

Most academic disciplines emphasize the importance of their general theories. Examples of well-known general theories include the Big Bang theory, Maxwell's equations, the theory of the cell, the theory of evolution, and the theory of demand and supply. Less known to the wider audience, but established within their respective fields, are theories with names such as the general theory of crime and the theory of marriage. Few general theories of software engineering have, however, been proposed, and none have achieved significant recognition. This workshop, organized by the SEMAT initiative, aims to provide a forum for discussing the concept of a general theory of software engineering. The topics considered include the benefits, the desired qualities, the core components and the form of a such a theory.

Today, it is practically impossible to provide a complete undergraduate education within software engineering, not only because of its breath and depth but also due to its complexity, intricate nature and huge competition from other curriculum subjects. In this paper, we suggest a half-day tutorial providing one angle of teaching software engineering and tackling the incompleteness problem. The tutorial is based on the ESSENCE Kernel, a recently accepted OMG standard. The Kernel covers the domain of software engineering in a minimalistic way. It includes specifications of the essential things that must be considered for assuring the progress and health of every software engineering endeavor. Hence, it provides a good basis for embracing the whole software engineering domain in a simple yet fully covering manner.

The scope of software engineering has become enormous and impossible to teach it in its entirety. Hence, educational programs should focus on a subset of its body of knowledge. In this paper, we suggest Reuse and Progress Driven Software Engineering Educational Method (RaPSEEM). The method aids in organizing the software engineering body of knowledge when designing specific software engineering programs.

The IEEE 1219 standard is too general. It proposes one generic process model for all maintenance categories. However, maintenance categories differ too much. Hence, they cannot be reflected in one generic model. In this paper, we match Corrective Maintenance Maturity Model and parts of Evolution and Maintenance Maturity Model against the IEEE 1219 standard. Our results show that the IEEE 1219 standard must be revised to properly reflect the domain of corrective maintenance within industry.

Most of the standards and process models are not explicit enough about demarcating risk management responsibilities of project managers. Usually, they place them entirely on a project level. In this paper, we study the risk management responsibilities of project managers within 53 software companies. Our goal is to find out what exactly project managers do within pre-project and project activities such as requirements, project and task planning and what risk management responsibilities they have within these activities. Our results show that the responsibility portfolio of project managers varies depending on the degree of their engagement within pre-project and project phases; the broader the project managers' responsibility portfolio, the broader their risk management responsibility portfolio.

Organizations must be more forthright in their communication about risks. This is however not easy on an organization-wide basis where many different processes and roles are involved. In this paper, we evaluate a model of an intra-organizational risk management communication within 57 software organizations. Our results show that our model is mainly applicable within large companies.

Organizations, their businesses and contexts are multi-dimensional, diverse, and very complex today. Hence, creating homogenous process models for managing them may not always be an optimal solution. Instead, organizations should be able to tailor their processes to the formality level required for the context at hand. In this paper, we claim that the organizational maturity is not only about how organizations are capable to manage their processes. It is also about how capable they are in adapting them to specific contexts and business needs. We also suggest Context-Driven Process Orchestration Method (CoDPOM), based on the concept of practice choreography and process orchestration. The CoDPOM's role is to aid software practitioners in identifying process needs and in recognizing waste which, in turn, would aid them in adapting their software processes to specific contexts, business needs and formality levels.

Despite its age of almost half a century, software engineering is not yet mature enough. It still suffers from enormous gaps in the knowledge and understanding of software lifecycle processes and their reciprocal interplay and impact on each other. The gaps will stay with us if we do not put enough effort and resources into decreasing and/or removing them. This paper claims that the software community should pull together and make the effort of organizing itself and defining and/or redefining software engineering based on a solid theory, proven principles and best practices. The software community should create a process roadmap. Such a roadmap should list the processes to be managed during the lifecycle, place them on the organizational levels, place them on the software lifecycle phases, identify their role within each organizational level and lifecycle phase, weigh their business criticality and rate their research urgency.

It is high time we looked at the education of software engineering from a global and mobile perspective. To achieve this, we suggest a new educational paradigm, in which future software engineering students and lecturers are mobile and agile. They may enroll at any globally established educator providing educational services on various abstraction levels. This paper suggests a Globalization Ladder, a tool aiding the software community to develop a global software engineering education program

Even if we have recognized many short-term benefits of agile methods, we still know very little about their long-term effects. In this panel, we discuss the long-term perspective of the agile methods. The panelists are either industrial or academic representatives. They will discuss problems and benefits related to the long-term lifecycle system management in agile projects. Ideally, the panel's outcome will provide ideas for future research.

Software evolution and maintenance processes have been and continue to be an unexplored domain. Current process models and standards do not cover the whole evolution and maintenance domain. As a result, the software community still possesses a blurred understanding of its scope, an unclear picture of how various processes are interrelated, how they impact each other and the product. The software community is also insecure about how to adapt evolution and maintenance processes to new methods and technologies. This workshop aims at discussing the challenges, problems and evolution and maintenance process models according to the latest findings.

Little is known about problems encountered in distributed Agile development environments. There have been some case studies reporting on them. However, these studies have been mainly limited to the scope and context of only one or a few companies. As a result, we do not possess an overall picture of what types of problems and challenges the companies may encounter in distributed Agile environments. In this paper, we analyze twelve case studies from the existing literature, identify thirteen problems reported in them and their solutions, and we group the problems into six classes: Culture, Time Zone, Communication, Customer Collaboration, Trust, Training and Technical Issues.

Most of the effort has been spent on formalizing processes for system testing. Little has been done regarding developers' unit and unit integration testing. In this paper, we study the routines of six developers when testing their software components. Our contribution is twofold. It first outlines a process model for unit and unit integration testing. It then provides feedback on the state of practice within six organizations.

To continuously meet the changing needs of the customers, organisations follow their own enhancive maintenance process models. Unfortunately, these models are not easily available to the academic world. In this paper, we study enhancive maintenance in three organisations in Ghana. Our goal is to explore information about the initial phases of the enhancive maintenance process and put them into a process model Our model makes provision for process phases, their activities, roles, and data needed for managing enhancements. Although the primary goal of this paper is to elicit an enhancive maintenance model, we will not deny that it also provides the information on the state of enhancive maintenance practice in one developing country - Ghana.

Most of the testing process models deal with testing within development. To our knowledge, there are no process models exclusively dedicated to the testing of corrective changes. For this reason, we have outlined a process model covering the testing activities at the front-end support level and evaluated them within IS software organizations.

Transitioning to SOA is a complex process. It affects and is affected by many organizational components such as strategies, processes, organizational infrastructures, and the like. These components strongly interact, keep changing, yet provide guidance for an organization's management in migrating to the use of SOA in its information systems. This paper suggests a SOA-zation Framework (SF). The framework is based on the industrial practices as observed by the authors of this paper.

Cloud Outsourcing has shown to be a successful form of delegating tasks to individual programmers over the Internet in the context of small businesses. As a result, bigger companies are now strongly considering to practice it. Going over to Cloud Outsourcing, however, can be a very challenging task. It does no longer imply delegating some simple tasks to some outsourcees and acquiring their results. It implies a handover of complex system parts to be worked upon and a handover of knowledge and experience required for performing the tasks on the system parts. In this paper, we claim that the software community must define a proper handover process before embarking on Cloud Outsourcing. If we do not have such a process in place, we are likely to fail when delegating complex responsibilities to unknown parties over the Internet. In this paper, we also identify research questions that need to be answered before going over the Cloud Outsourcing mode.

26.

Kajko-Mattsson, Mira

et al.

KTH, School of Information and Communication Technology (ICT), Software and Computer systems, SCS.

Many intellectual, societal, business and technological forces are continuously pushing forward the frontiers of science. When combined, they provide an umbrella for generating new fields and exploring new grounds. One such a new field is e-Maintenance. e-Maintenance addresses new needs and provides various benefits in form of increased availability, reduced lifecycle cost and increased customer value. However, it suffers from lack of a commonly defined basis supporting the existence of e-Maintenance and determining the essential components inherent in the e-Maintenance domain. In this paper, we suggest an initial set of components that serve as the groundwork of the e-Maintenance universe. The set outlines ten initial components. These are definition, business,organization, product,service,methodology,technology,information,customer,and education and training. The paper also suggests a definition of e-Maintenance, places eMaintenance in the context of other e-Domains, and elicits e-Maintenance intellectual opportunities and challenges to be met by both the academia and industry.

Handing over a software system from development to maintenance is still an under-researched domain. The software community has a hazy insight into its constellation and inherent activities. In this paper, we have evaluated a preliminary version of a taxonomy of handover activities within one Swedish software company. The evaluation is conducted in an in-house handover context only. Despite this, our results provide evidence of its enormous complexity, variability and strong dependency on many other software engineering processes.

Development, evolution and maintenance of SOAbased systems demands rethinking of the traditional roles for performing these activities. The key objective of this paper is to present preliminary ideas on the roles required for developing, evolving and maintaining SOA-based systems and to suggest a framework for areas of needed research.

As SOA-based systems are becoming more common, there is a need to consider how traditional IT roles and responsibilities need to change. This paper proposes a framework for roles that are required for evolving and maintaining SOA-based systems. It builds on work on traditional IT roles, as well as insights emerging from current research on SOA. The paper also presents a questionnaire for collecting data from organizations on roles that they use for SOA-based systems maintenance and evolution. Results from a pilot use of the questionnaire with Scandinavian Airline Systems (SAS) are presented.

As part of globalizing education, the Linnaeus-Palme programme offers universities to exchange lecturers. Two departments coming from China and Sweden utilized this opportunity. A Swedish professor gave a course on software lifecycle management in China. In this paper, we report on a teaching experience gained during this programme. This experience indicates that there are no national boundaries when teaching software engineering. It also provides an important point of reference for improving current educational exchange programmes.

Many software development and evolution projects use risk management process for tackling various uncertainties, unexpected events and unclear project prerequisites. Despite this, little is known about their effectiveness. In this paper, we report on the status of risk management practice within five organizations. The report encompasses issues such as (1) industrial understanding of risk, (2) project uncertainty, (3) risk management within projects, and (4) use of risk management process.

The ability to deliver support according to predetermined Service Level Agreements (SLAs) has become an important success factor. To be able to do it, organizations need a sound SLA management process model. Presently, they base their SLA management strategy on standardized frameworks, such as ITIL or COBIT. However, due to the complexity of these frameworks, organizations need simpler models that can be easily implemented. In this paper, we outline an SLA Management process model and evaluate it within four organisations.

The purpose of documentation is to describe software systems and software processes. Consistent, correct and complete documentation of a software system is an important vehicle for the maintainer to gain its understanding, to ease its learning and/or relearning processes, and to make the system more maintainable. Poor system documentation, on the other hand, is the primary reason for quick software system quality degradation and aging. Proper process documentation records the process, its stages and tasks, executing roles, their decisions and motivations, and the results of each individual process task. It is extremely important for achieving insight and visibility into the processes, important for their meaningful process measurement and thereby pivotal for achieving high process maturity. In this paper, we report on the results of an explorative study in which we have identified a number of rudimentary documentation requirements relevant within corrective maintenance, and found out how they were implemented within eighteen software organizations in Sweden. The goal was to examine the industrial documentation practice within corrective maintenance. Our results show that the documentation within corrective maintenance is still a very neglected issue within the organizations studied. None of our organizations has fully implemented all our documentation requirements.

34.

Kajko-Mattsson, Mira Miroslawa

KTH, School of Information and Communication Technology (ICT), Computer and Systems Sciences, DSV.

We have created a process model for managing corrective maintenance requests at the front-end support level. Our model is called CM3: Front-End Problem Management. It was elicited at two ABB organisations and refined at Cap Gemini Ernst &amp; Young and Scandinavian Airline Systems. In this paper, we evaluate it on a major scale using feedback from 15 major software organisations. The evaluation results show that CM3: Front-End Problem Management appropriately mirrors the industrial reality.

CM3: Problem Management is a first detailed descriptive problem management process model to be utilized within corrective maintenance. It is the result of a long-term empirical study of industrial corrective maintenance processes. It has been developed at ABB and evaluated for its industrial relevance within 17 non-ABB organizations. Playing the role of a descriptive model, CM3: Problem Management specifies what a problem management process should look like. It also structures it into three maturity levels, Initial, Defined, and Optimal, where each level offers a different grainedness of process visibility. In this paper, we present the CM3 levels of problem management process maturity within corrective maintenance and match them against the industrial state of practice. Our goal is to establish the current status of problem management maturity using CM3: Problem Management as an evaluation model. Our evaluation results show that the industrial processes today suffice to attend to software problems within corrective maintenance. Very few of them, however, do learn from the past in order to prevent future problems and to improve development or maintenance processes.

Within corrective maintenance, the front-end support mainly assists the customer- and back-end maintenance organizations in the communication of corrective maintenance demands. This implies receiving problem reports from customers, transferring them on to the back-end maintenance organization/vendor, and delivering problem solutions from the back-end maintenance organization/vendor to the customers. In this paper, we identify problems as experienced within 37 front-end support organizations in Sweden. Our results show a great variety of problems within the organizations studied. The dominating problems are the complexity of applications, customer knowledge, and complexity of support organizations.

Little is known about Chinese software development. lit this paper, we report air the status of requirements management within six Chinese companies. We investigate the pre-implementation phases on business and engineering levels and documentation utilized within the whole development process.

To be able to provide support to the customers in their daily operation, one must not only have an efficient support process, but also an agreement on the types and quality of the services to be provided Such an agreement is usually called Service Level Agreement (SLA). In this paper, we suggest an SLA model and show how it is realised within four organisations in Sweden. Our model is called CM(3) : SLA, and is part of a major model called CM(3) : SLA/OLA.

Consider two independently done software engineering studies that used different approaches to cover some of the same subject area, such as software maintenance. Although done differently and for different purposes, to what extent can each study serve as a validation of the other? Within the scope of the subject area overlap, data mining can be applied to provide a quantitative assessment. This paper reports on the data mining that attempted to cross validate two independently done and published software engineering studies of software maintenance, one on a corrective maintenance maturity model, and the other on an objective classification of software maintenance activities. The data mining established that each of the two independently done studies effectively and very strongly validates the other.

A well-functioning process for reporting, analysing and resolving software problems is an important vehicle for establishing and I retaining control over the development and maintenance of software products, In this paper we present such a process. its state of practice and its role within corrective software maintenance. This process is utilized at ABB Robotics AB and is called the System Progress Report process (SPR), The SPR process is the result of our 20 years of work and experience. This paper concludes with our lessons learned and plans for future improvements.

The software engineering discipline has been quite successful in creating various development models for constructing software systems. It has not however been that successful in creating later lifecycle process models. One of them concerns retirement. In this paper, we elicit a retirement process model and compare it to the current standard retirement process models. Our goal is to evaluate current retirement process standards and provide feedback for their extension. The elicitation process has been made within one Nordic financial company.

Although software engineering has been quite successful in creating various development models, it has failed in defining later lifecycle process models. One of such process models concerns retirement. In this paper, we elicit a retirement process model and compare it to the standard models. Our goal is to evaluate current retirement process standards and provide feedback for their extension.

Successful postdelivery and postrelease maintenance highly depends on the degree of engagement of maintenance organisations during the predelivery and prerelease maintenance phases. In this paper, we suggest taxonomy of predelivery and prerelease activities. This taxonomy is consistent with the ISO/IEC 14764 standard and it has been elicited within eight Swedish organisations.

We were commissioned to establish one organisation's possibility to implement a daily build process. For this purpose, we have developed a model aiding us in evaluating, the organisation's readiness to implement the process. In this paper, we present our evaluation model and the lesson learned from using it when attempting to determine the organisation's readiness to fully integrate a daily build process with their already extant software development and evolution processes.

Little is known about the industrial opinion of the effectiveness of risk management. In this paper, we report on this opinion as expressed by five software organizations. According to these organizations, risk management should be a driving wheel of all projects and it should help the organizations dare take big risks in projects that might lead to high opportunities. The amount of resources assigned to risk management should depend on parameters such as product criticality, project size and project type. Finally, the organizations studied could not provide any concrete suggestions for how to evaluate risk effectiveness. All of them do risk management evaluations in a highly subjective manner.

Today, there are no detailed standard process models encompassing the overall release management activities. To remedy this, we have created an individual release management process model, called EM(3): Release Management. In this paper, we evaluate its acceptor side against an industrial release management process performed at Scandinavian Airline Systems (SAS). We have observed some similarities and differences. Some of the observed differences will provide feedback for the improvement and further extension of EM(3): Release Management.

Emergency software problems may present an immediate danger to public health, safety, general welfare or business. Hence, the organisations must be well prepared to handle them with the greatest expediency. Unfortunately, the software community has paid little attention to the emergency corrective maintenance. Today, we do not have any standard process models for handling emergency situations. In this paper, we outline an emergency corrective maintenance process model. The model is called CM3: Emergency Problem Management. It is based on an industrial process model as defined at Scandinavian Airline Systems. In addition to the emergency process model, we present the status within the emergency process at Scandinavian Airline Systems, and describe the lessons learned.

50.

Kajko-Mattsson, Mira Miroslawa

et al.

KTH, School of Information and Communication Technology (ICT), Computer and Systems Sciences, DSV.

Nyfjord, Jaana

KTH, School of Information and Communication Technology (ICT), Computer and Systems Sciences, DSV.

Structured and disciplined communication is a prerequisite for effective management of requirements. In this paper, we investigate what requirement management information is communicated within a software development cycle. We do this by studying the management of requirements information within one Canadian organization. Our results show that most of the information as designated in our template is recorded by the organization studied.