This report analyzes ten experience reports about software process improvement (SPI) projects at different companies. Several lessons learnt are listed from each report and used to derive factors that define the success and failure of SPI projects. The generated factors are combined and aggregated. Finally it is suggested how these factors can be used in order to contribute to the health of SPI products.
Abstract
This report analyzes ten experience reports about software process improvement (SPI) projects at different companies. Several lessons learnt are listed from each report and used to derive factors that define the success and failure of SPI projects. The generated factors are combined and aggregated. Finally it is suggested how these factors can be used in order to contribute to the health of SPI products.
Keywords: SPI, Software Process Improvement, Health of Software Process Improvement Process, experience report, industry report, success factors.
1 Introduction
In order to learn about the realization of successful software process improvement (SPI) projects, certain success factors can be derived. A lot of research has been conducted to identify such factors [1], not only from successful projects but also from failed projects as they provide valuable insights as well. The goal of this report is to contribute to the research issue by listing and analyzing experiences of succeeded and failed SPI projects including the extraction of success respectively failure factors from overall ten industrial SPI experience reports. By analyzing SPI projects using such factors, conclusions about the status and health of the projects can be drawn. Thus, these factors are an indicator to be able to state about the projects. They can furthermore be used as a basis to derive guidance of how to improve the health of SPI projects. Healthier SPI projects are more likely to be successful, because they are said to be healthy justbecausethey better meet known factors, which determine the success of such initiatives.
In fact, performing a SPI project often means using a certain process model to be carried out “as a vehicle”, e.g. Capability Maturity Model Integration® (CMMI, formerly just CMM) [2]. There exist other models like ISO 15504 (also called “SPICE”) and ISO 9001. The experience reports analyzed in this report mostly use CMM / CMMI, which is also one of the most frequently used models for SPI [2]. However some reports are based on SPI initiatives that do not use specific process models. The mentioned models do not contain precise information abouthowto conduct successful SPI projects, but morewhathas to be done from the technical process perspective. This is a reason why advice about the project initiative itself should be given, and extracted and generalized success factors of SPI projects are suitable to meet this demand. In addition, SPI activities are mostly conducted via project organization. This organizational structure comes along with special properties and is frequently discussed. To perform successful projects a lot of knowledge and technics are required, if the project’s faith should not be relied on chance. SPI projects are even more specific and therefore need special treatment and guidance. To contribute to this knowledge generating success factors is a proper means.
After all SPI itself is important to continuously improve processes and thus also the products that are developed using the software process. High quality software products are crucial in order to face the market successfully.
2 Research Method
To conduct this report ten industrial experience reports about SPI projects is analyzed. These reports tell about concrete experiences and results from single SPI projects and processes in companies. These reports are searched for at online databases amongst others like IEEE Xplore [3], Wiley Online Library [4], ACM [5] and Libris [6]. These experiences are listed in chapter 3 and afterwards analyzed by extracting factors that influence success and failure of SPI projects. It is further questioned, how these factors can contribute to the improvement of the health of SPI projects in Chapter 5.
3 State of the art
The following chapter lists experiences from failed and succeeded SPI initiatives. However, it is often not clear how to distinguish between success and failure at these projects, because in the very most cases some improvements are measured, although some other targets have not been achieved. The numbering of the experience reports is allocated continuously within chapter 3.1 and 3.2.
3.1 Experiences from failed SPI projects
Experience report 1. The report “Toward Computational Support for Software Process Improvement Activities” [12] analyzes an SPI project at OMRON (Japan) starting in 1995. “OMRON produces a variety of highly automated mechanical systems” [12]. The overall target was to improve the software processes. First, the project plan was revised after the project was delayed. Further plans have been missing, although some activates were still going on. The following experiences were made [12]:
- “fluctuating goals, and the lack of a shared goal among the process improvement project members.”
- “no visualized status of the SPI project, and no systematic assessment schemes for SPI activities but only abstract qualitative analyses.”
- “poorly managed many different types of unstructured information.”
- “unclear role distributions among many stakeholders including SEPG[(Software Engineering Process Group)]members, developers, project managers, and top management.”
- “hardly transferred technology for new SEPG members. know-hows existed but depended on members’ expertise”[12].
[...]
- Quote paper
- Rano Istlow (Author), 2011, Health of Software Process Improvement Process, Munich, GRIN Verlag, https://www.grin.com/document/214266
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.