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.

Despite substantial amount of research in software process improvement (SPI) and a wide variety of SPI approaches and software process maturity models, many of the SPI initiatives still fail. This is mainly because the improvement projects are found to be far more complex than expected from the beginning. They embrace a myriad of various organizational, managerial, process, and social properties that need to be considered, such as clear directions, full commitment, continuous sponsorship, and dedicated resources. Some of those properties have been already widely known within SPI arena while others have not yet been recognized. This paper identifies the properties that need to be fulfilled for making SPI projects successful and puts them into an SPI Checklist to be used in the assessment of SPI projects. It then reports on its pilot evaluation within 10 SPI projects at Rolls Royce. The evaluation results show a strong relationship between the fulfillment of the checklist items by the projects studied and the success rates of those projects. Thereby, the results provide a strong proof of concept demonstrating that the success of SPI projects is no accident but a foreseeable outcome of clearly identified and assessable characteristics. Copyright © 2015 John Wiley & Sons, Ltd.

Literature shows that as many as 82% of the organizations that adopt agile methods experience problems in their agile adoptions. Despite this, very few reports have provided guidelines for how to conduct software method adoption. This paper suggests a process model of software method adoption and lists contextual factors for guiding the deployment of software development methods. The adoption model and the contextual factors have been evaluated in six industrial method adoption projects and they have proven to be useful for guiding organizations in their software method adoption efforts.

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.

Transitioning from one software development method to another has become a common routine for many companies. Despite this, very few reports give clear and detailed guidelines on how to conduct a process transition. This paper reports on two real-life process transitions and suggests a general process model of Software Method Transition (SoMeT). The SoMeT model aims to guide a transition from one software method to another.

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 new software engineering initiative, Semat, is in the process of developing a kernel for software engineering that stands on a solid theoretical basis. So far, it has suggested a set of kernel elements for software engineering and basic language constructs for defining the elements and their usage. This paper describes a session during which Semat results and status will be presented. The presentation will be followed by a discussion panel.

Transitioning from one development method to another has become a common routine for many companies. Despite this, very few reports describe how the process transition has been carried out, and provide suggestions for how to define a process transition model. This paper reports on a process transition from Scrum to Scrumban in one software development company. The paper gives an account on the process transition process, changes done to the development process undergoing the transition and the improvements achieved. It rounds up with lessons learned.

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.

Even if most of the software process transitions have been made with the goal of improving software processes, only few experience reports recognize process transition as an important element of software process improvement. This paper reports on a developer-driven Big-Bang process transition from Scrum to Kanban, and recognizes it as part of process improvement effort in one software development company. The paper reports on the transition process, changes done to the process and results achieved. It rounds up with an initial model of a process transition, lessons learned from the process transition effort and suggestions for future work.

Predelivery maintenance is one of the processes that has not received enough attention both within the academia and industry. Still, it counts as one of the least visible lifecycle processes. In this paper, we make it more visible by demarcating its scope within software lifecycle. We do it within eleven companies. Our goal is to find out how the industry understands predelivery maintenance and how it places it within software lifecycle. Our results show that predelivery maintenance is conducted by all the organizations studied in five different contexts. These organizations however use different terms for it or they treat predelivery maintenance as part of other processes. For this reason, we conclude that predelivery maintenance is a process that cross-cuts several lifecycle processes.

Despite the fact that a handover process is just as frequently performed as any development process, little is known about it. Still, it is regarded as one of the lifecycle processes that is not well explored and defined. In this paper, we study the handover process within eighteen companies with the purpose of demarcating its scope within software lifecycle. Our goal is to find out how industry understands handover process and how it places it within software lifecycle. As a result, we have identified seven different scope contexts for the handover process. We have also provided evidence of its wide lifecycle span and its overlap with development, predelivery and postdelivery maintenance processes.

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.

Process changes do not always lead to changes for the better. They may lead for the worse or they may not imply any improvements at all. In this paper, we report on the results of two process transitions in Mobile Navigation. By looking at the problems and benefits as encountered before and after each transition, we conclude that many of the problems are organization and people related. A method cannot help to improve the process if people and organizations do not follow it. Both organizations and people must mature with respect to management, self-organization, and discipline. It is only then the newly introduced method will improve the process for the better.

Some agile voices have been raised against extensive documentation. They advocate its sparse use and production. In this paper, we report from agile evolution and maintenance trenches on the lifecycle problems related to system and process documentation. Our report gives an indication of the problems that have been encountered within 18 agile organizations.

The ability to deliver support according to pre-determined 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.

Daily build testing has proved to be an effective tool for managing integration problems. Introducing it however requires major changes to the whole development process and organizational culture. In this paper, we tell a tale of two organizations being in the process of introducing daily build practice into their organizations: one successful and one unsuccessful. Our results show that a daily build process is not amenable for a step-wise implementation. The majority of its requisite components must be in place before the process is introduced.

Little is known about of how software embedded in complex industrial technical systems is maintained. In this paper, we identify industrial maintenance process steps and position software maintenance activities within them. We do this in the context of JAS 39 Gripen, a multi-role combat aircraft developed by Saab.

Little is known about the compliance of risk management models with the industrial practice and vice versa. In this paper, we compare the industrial risk management practice against a risk management model that we have synthesized from a set of current risk management models. This comparison has resulted in several discrepancies observed. As a result, this paper suggests a list of issues that need to be addressed in both the industrial and standard models.

Little is known about the industrial practice of modernising legacy systems. To be able to study it, we have created RaMoLeS - an end-to-end process model for modernising legacy systems. It consists of four sub-models: (1) Assessment, (2) Retirement, (3) Reengineering, and (4) Renovation. It provides guidelines for making decisions on how to approach ageing systems. In addition, it designates activities for each of its sub-models. In this paper, we evaluate the state of modernising practice in four major Swedish organisations using RaMoLeS. Our results show that most of the organisations studied do not have any defined end-to-end modernisation process model to follow. However, they conduct most of the activities as designated in the RaMoLeS framework.

It may not be enough to develop mature processes at the back-end support level. Other strongly collaborating front-end support processes may substantially undermine them. For this reason, we have created CM3: front-end problem management - a detailed problem management process model to be utilised at the front-end support level. In this paper, we present the CM3maturity levels at the front-end support and match them against the industrial state of practice within 15 software organisations. Our goal is to establish the current status of support maturity using CM3: front-end problem management. Our results show that the industrial processes studied suffice to provide basic problem management support at the front-end support level. However, only two out of 15 organisations studied have almost achieved the highest maturity level.

On the surface, agile and risk management process models seem to constitute two contrasting approaches. Risk management follows a heavyweight approach whereas agile process models oppose it. In this paper, we identify commonalities in these two process models. Our results show that they have much in common, and that a merge between them is possible.

The main goal of this working session is to provide an opportunity for participants to present current work and have a lively discussion of open issues for the maintenance and evolution of SOA-based systems. The dialog will include both business issues (e.g., organizational changes in the context of migrating to an SOA environment) and technical issues (e.g., analyzing the reuse potential of legacy components in an SOA environment). A draft version of a research agenda will be used as a starting point for obtaining feedback from researchers and practitioners active in this area.

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 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 15 software organizations.

Dissatisfaction with heavyweight development approaches has lead to a proposal of agile methodologies. While heavyweight approaches are geared towards careful project planning, formalized quality assurance, and controlled and rigorous software development processes, the agile approaches focus on quick adaptation to change, and flexibility. Today, there are a number of different agile methods available, such as Scrum, Crystal, Adaptive Software Development, Feature Driven Development, and extreme programming. Although different, they share the same principles. Some of them are: (1) individuals and interactions over processes and tools, (2) working code over comprehensive documentation, (3) customer collaboration over contract negotiation, and (4) responding to change over following a plan. The proponents claim that agile methodologies lead to more effective and efficient development. The opponents, on the other hand, have stamped the agile approach as a "license to hack" or "cowboy", or "code-and-fix" method.

In this paper, we propose SERVIAM maintenance framework - a framework for evolving and maintaining Web services. Our framework includes organisation, role, and process changes to accommodate Web service product and use characteristics.

In this paper, we suggest a panel debate on evolution and maintenance of web services. The panel will discuss the evolution and maintenance of web service applications.

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/sup 3/: SLA, and is part of a major model called CM/sup 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.

Abstract 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. Copyright © 2004 John Wiley & Sons, Ltd.

Service quality has become a critical survivability factor. The value of IT-business does not only lie in the products but also in the needs it serves. More and more customers require the IT companies with which they do business to continuously improve the speed and quality of their service. To provide seamless high quality service, the collaborating IT-companies/departments must organize themselves in a way so that they can act as one virtual enterprise providing a single point of contact. In this paper, we study how thirty eight companies belonging to thirty seven independent virtual enterprises have organized themselves in order to provide optimal maintenance service to their customers. Our goal is to provide a basis for future support process models and for future business models. Our results show strongly diversified infrastructures of confluent service organizations. These infrastructures were matched against CM/sup 3/: Roadmap: Organizational Perspective.

We present our PhD thesis, in which we suggest a process model for handling software problems within corrective maintenance. Our model is called CM/sup 3/: Problem Management.

Abstract CM$^3$ : 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, CM$^3$ : 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 CM$^3$ 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 CM$^3$ : 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. Copyright © 2002 John Wiley & Sons, Ltd.

Close scrutiny of software preventive maintenance has revealed that this domain is not unanimously and objectively understood. Confusion predominates with respect to its definition, scope and meaning. The author presents the current state of software preventive maintenance and delineates the disorder reigning in this area. A survey is also given of hardware preventive maintenance in search of issues of interest to be applicable within software preventive maintenance.

Many process models have been hitherto suggested. Very few of them, however, deal with the most utilised process today: the maintenance process. The article presents and motivates the "Corrective Maintenance Maturity Model" (CM/sup 3/), a process model entirely dedicated to only software maintenance.

What is the point of improving maintenance processes if the most important asset, people, is not properly utilised? Knowledge of the product(s) maintained, maintenance processes and communications skills is very important for achieving quality software and for improving maintenance and development processes. We present CM/sup 3/: Maintainer's Education and Training-a maturity model for educating and training maintenance engineers. This model is the result of a comparative study of two industrial processes utilised at ABB, and of process models such as IEEE 1219, ISO/IEC 12207, CMM, People CMM, and TickIT.

Consistent, correct and complete documentation is an important vehicle for the maintainer to gain understanding of a software system, to ease the learning and/or relearning processes, and to make the system more maintainable. Former studies have shown that documentation is one of the most neglected process issues within software engineering today. The authors check the current state of documentation practice within corrective maintenance in Sweden.

In this paper, we present our suggestion for a business maintenance model. We call it "Corrective Maintenance Maturity Model" (CM/sup 3/). In contrast to other process models, it is a specialised model, entirely dedicated to only corrective software maintenance. It views maintenance in terms of the activities to be performed and their order, in terms of the information utilised by these activities, goals, rules and motivations for their execution, and organisational levels and roles involved at various stages of the corrective maintenance process.

Successful postdelivery and postrelease maintenance highly depends on the degree of engagement of maintenance organisations during the predelivery and prerelease phases. In this paper, we have compiled the state of predelivery and prerelease practice in eight major organisations in Sweden. We did this using mainly the ISO/IEC FDIS 14764 standard as an evaluation template. Hence, our study can also be conceived as an attempt to evaluate the usability of the ISO/IEC FDIS 14764 standard in an industrial context. We round off this paper by suggesting some extensions to the ISO/IEC FDIS 14764 standard.

Inconsistency exists within the software community surrounding the understanding of and adherence to the IEEE definition of preventive maintenance, due to the congruence between the IEEE definitions of perfective and preventive maintenance. A panel debate is advocated to discuss the definition and current state of preventive maintenance practice.

Was all the mania lending up to the turn of the millennium warranted or was it just a load of computer maintenance ballyhoo designed to attract attention? In this paper, we spot-test a selected number of Swedish companies to establish their state of preparedness just prior to meeting the new millennium as well as the effects they have encountered immediately after the turn of the millennium. These are then compared to the list of effects compiled by the Millennium Commission (appointed by the Swedish Government).

A well-functioning process for reporting, analysing and resolving software problems is an important vehicle for establishing and 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. Copyright © 2000 John Wiley & Sons, Ltd.

In large software organisations, a maintenance process is seldom monolithic. Instead, it is a complex family of various processes collaborating with each other where each process executes a clearly defined task. In this paper, we present a comparative study of maintenance processes utilised by two ABB organisations, namely ABB Automation Products AB, and ABB Robotics AB. These processes administer the management of software problems. Thus, this study could be regarded as a report on the state of maintenance practice at the present moment.

Software engineering is the fastest growing field of engineering today. Due to this revolutionary development, many conflicts have arisen when defining and using new concepts. This has involved the need for standards, such as the IEEE standard. Despite this, there is still nonuniformity in the use of standard definitions. This could be due to the fact that most of the standard definitions are expressed in natural language. Furthermore, ambiguity may arise when relating some of these concepts to other concepts. We propose a conceptual model of the basic concepts utilised within corrective software maintenance. The goal is to clarify the fundamental concept apparatus. This model should constitute a common forum for communication when conceptualising software problems and defects, and for suggesting maintenance frameworks, models and/or measures.

For pt.I see Internat. Conf. Software Maintenance (1999). In large software organisations, a software maintenance process is seldom monolithic. Instead, it is a complex family of various processes collaborating with each other, where each process executes a clearly defined task. We describe and compare two change execution processes utilised within maintenance by two ABB organisations, namely ABB Automation Products AB and ABB Robotics AB. Thus, the paper is the report of the current state of practice in change execution at ABB. It also compares the collaborating maintenance processes used for the administration of software problems.

Four distinct maintenance systems are studied and synthesised: the SEI quality framework and three industrial systems belonging to ABB, Ellemtel, and Ericsson. The goal is to validate the SEI framework, and to build a "state of the practice" conceptual model of the most fundamental software maintenance concepts. This model can help understand the underlying conditions for managing software maintenance. It can provide guidance to organisations in the process of building or improving their maintenance systems. It also constitutes a common basis for communication, for reasoning about software quality, and for building quality and maintenance models.