Software Process Improvement

This paper explores the operational context of software processes and how it can inform the micro-process level environment. It examines the case of software project performance, describing a novel explanation. Drawing on the management literature, project performance is modeled as the contested outcome of learning as a driver of success and certain barrier conditions as drivers of failure, through their effects on organizational capabilities. A case study illustrates application of the theory. Implications of this macro-process case for micro level software process improvement are discussed.

(1) causal analysis meetings to identify the root cause of defects and sug gest preventive actions; (2) an action team to implement the preventive actions; (3) kickoff meetings to increase awareness of quality issues specific to each development stage; and (4) data collection and tracking of associated data. The Defect Prevention Process has been successfully implemented in a variety of organizations within ISM, some for more than six years. This paper discusses the steps needed to implement this process and the results that may be obtained. Data on quality, process costs, benefits, and practical experiences are also presented. Insights into the nature of programming errors and the application of this process to a variety of working environments are discussed. T o achieve quality software products, most de- velopment processes rely on defect detection and correction through inspections, walkthroughs, and reviews early in the development cycle, and through extensive testing. However, reliance on detecting defects after they have been injected is costly. The detection and correction of defects does not add function to the end product. Inspections and testing are also limited in effectiveness. A much more effective approach involves preventing defects from being injected during development. Fewer defects during development permits more resources to be devoted to developing new product function, and higher product quality in the field means greater customer satisfaction.

CMMI contains a collection of Process Areas (PAs), each of which contains many Specific Practices (SPs). However, the CMMI specification does not provide any explicit recommendation about which individual SPs can or should be implemented before other SPs. In this paper we identify dependencies between CMMI SPs in PAs in maturity level 2, and between the PAs. We analyzed the text of the CMMI specification to identify every Work Product (WP) produced and used by every SP in maturity level 2. Our analysis was validated by independent researchers and comparison with an existing dependency analysis shown in CMMI training materials. Our results have significance as a reference model of SP and PA dependencies for both SPI researchers and practitioners. For researchers we have provided an explicit representation of SP and PA dependencies that were previously only implicit in the CMMI specification. For practitioners, our results may provide guidance on the order of implementation of SPs and PAs. Our dependency analysis has limitations in being derived from the text of the CMMI specification -we have no direct evidence that these dependencies are valid in practice.

This paper explores the operational context of software processes and how it can inform the micro-process level environment. It examines the case of software project performance, describing a novel explanation. Drawing on the management literature, project performance is modeled as the contested outcome of learning as a driver of success and certain barrier conditions as drivers of failure, through their effects on organizational capabilities. A case study illustrates application of the theory. Implications of this macro-process case for micro level software process improvement are discussed.

This paper explores the operational context of software processes and how it can inform the micro-process level environment. It examines the case of software project performance, describing a novel explanation. Drawing on the management literature, project performance is modeled as the contested outcome of learning as a driver of success and certain barrier conditions as drivers of failure, through their effects on organizational capabilities. A case study illustrates application of the theory. Implications of this macro-process case for micro level software process improvement are discussed.

Nowadays, the pace of business change is such that, increasingly, new functionality has to be realized and reliably installed in a matter of days, or even hours. Consequently, more and more business processes are prone to a continuous change. The objective of the research in progress is to use the MAP model, in a conceptual modeling method for flexible and adaptive business process. This method can be used to capture the flexibility dimensions of a business process; it takes inspiration from modularity concept in the object oriented paradigm to establish a hierarchical construction of the BP modeling. Its intent is to provide a flexible modeling that allows companies to quickly adapt their business processes.

Nowadays, distributed development is common in software development. Besides many advantages, research in the last decade has consistently found that distribution has a negative impact on collaboration in general, and communication delay and time to complete tasks in particular. Adapted processes, practices, and tools are demanded to overcome these challenges.We report on an empirical study of communication structures and delay in IBM's distributed development project Jazz. The Jazz project explicitly focuses on distributed collaboration and has adapted processes and tools to overcome known challenges. We explore the effect of distance on communication and task completion time and use social network analysis to obtain insights about the collaboration in the Jazz project. We discuss our findings in the light of existing literature on distributed collaboration and delays. Copyright © 2008 John Wiley & Sons, Ltd.

The scale and complexity of change in software process improvement (SPI) are considerable and managerial attention to organizational culture during SPI can therefore potentially contribute to successful outcomes. However, we know little about the impact of variations in organizational subculture on SPI initiatives. On this backdrop, we report from a large scale SPI project in a Danish high-tech company, Terma. Two of its business units -Integrated Systems (ISY) and Airborne Systems (ASY) -followed similar approaches over a two year period, but with quite different outcomes. While ISY reached CMMI level 2 as planned, ASY struggled to implement even modest improvements. To explain these differences, we analyzed the underlying organizational culture within ISY and ASY using two different methods for subculture assessment. The study demonstrates how variations in culture across software organizations can have important implications for SPI outcomes. Furthermore, it provides insights into how software managers can practically assess subcultures to inform decisions about and help prepare plans for SPI initiatives.

Contrary to the basic tenants of the information technology project management literature, this research adopts a positive stance towards current practices. We report from a one-year action research effort in which we applied appreciative inquiry to improve project management practices at a small software firm, TelSoft. The paper presents our design of the appreciative inquiry process; it describes the resulting intervention into project management practices; and it discusses the results and the lessons learned.

Dimensions such as tacit-explicit and personalised-codified have been suggested as vehicles to understand the dynamics of knowledge in the context of professional work. The conventional wisdom is that these underlying perspectives on knowledge are alternatives, inviting either a focus on tacit-explicit or on personalised-codified knowledge. In addition however, the terms 'explicit' and 'codified' tend to be used interchangeably. Here we argue that explicit and codified knowledge focus on distinct and different a spects of professional work and these underlying perspectives should be seen as complementary rather than competing. As a consequence we need to critically rethink the role of codification in knowledge management and on that basis review our understanding of the dynamics of professional knowledge. Drawing upon insights from the systems development profession we propose to distinguish between tacit and explicit knowledge and between informal and codified knowledge as two complementary dimensions of knowledge. This leads to four distinct archetypes of professional knowledge -procedural, community, exemplary, and situated knowledge -and as a consequence to a revised perception of the dynamics involved in knowledge conversion from one type to another. The paper concludes with a critique of the conventional wisdom on knowledge management and with a discussion of the implications of our argument for both research and practice.

Capability Maturity Model Integration (CMMI) is a framework known for improving the quality of processes on consistent basis. This paper makes an attempt to explore, analyze and describe the impact of CMMI in terms of return on investment (ROI) for the IT industry. An IT organization who has acquired a maturity level of CMMI 2 is taken as case study. At first, in reference to the level of applied CMMI, a thorough study is completed. Afterwards the luxuries and limitations are studied and explored with reference to organizations applying the monetary terms using ROI framework. Finally, the presented research highlights the key benefits and difficulties in switching to CMMI from conventional quality assurance.

Top-down approaches to process improvement based on generic "best practice" models (e.g., CMM, TRILLIUM, BOOTSTRAP, SPICE) have become popular. Despite the idiosyncrasies of each of these approaches, they share some common characteristics: all of them are based on numerous assumptions about what are best practices, and about the business goals of organizations and the problems they face. Other organizations, like the Software Engineering Laboratory of the NASA Goddard Space Flight Center, HP and CRIM in Canada, have adopted the Quality Improvement Paradigm (QIP). The QIP stipulates a more bottomup and inductive approach to process improvement. The focus of this paradigm is to first understand what processes exist in the organization and to determine what causes the most significant problems. Based on this, opportunities for improvement are devised, and empirical studies are conducted to evaluate potential solutions. In this paper, we present a method, named AINSI 1 (An INductive Software process Improvment method), which defines general but concrete steps and guidelines for putting in place the QIP. This method is the result of the collective experiences of the authors and integrates many lessons learned from process improvement efforts in different environments. It also integrates many complementary techniques such as qualitative analysis, methods for data collection (e.g., the Goal/Question/Metric paradigm), and quantitative evaluation.

The success of information systems (IS) projects continues to be low despite many initiatives to address the issue. Given the importance of IS for organizations, it is a key imperative for software development firms to understand what is needed to deploy high-quality and successful systems. This is systems that are adopted and used, which by extension can contribute to goal satisfaction and business value. The notion of successful systems is even more important for developing regions, such as the English-speaking Caribbean (ESC), as such regions have far less capacity to absorb these failures (when compared to software development firms in developed countries). Understanding the factors that impact the quality outcomes of IS projects (i.e. antecedents of IS success), is considered key to the success of these projects. This study therefore aims to provide a research model that identifies key factors impacting IS project quality and success, while taking into account the unique characteristics of developing countries (in this case, the ESC region).

Nowadays, distributed development is common in software development. Besides many advantages, research in the last decade has consistently found that distribution has a negative impact on collaboration in general, and communication delay and time to complete tasks in particular. Adapted processes, practices, and tools are demanded to overcome these challenges.We report on an empirical study of communication structures and delay in IBM's distributed development project Jazz. The Jazz project explicitly focuses on distributed collaboration and has adapted processes and tools to overcome known challenges. We explore the effect of distance on communication and task completion time and use social network analysis to obtain insights about the collaboration in the Jazz project. We discuss our findings in the light of existing literature on distributed collaboration and delays. Copyright © 2008 John Wiley & Sons, Ltd.

Measurement based software process improvement is nowadays a mandatory activity. This implies continuous process monitoring in order to predict its behavior, highlight its performance variations and, if necessary, quickly react to them. Process variations are due to common causes or assignable ones. The former are part of the process itself while the latter are due to exceptional events that result in an unstable process behavior and thus in less predictability. Statistical Process Control (SPC) is a statistical based approach able to determine whether a process is stable or not by discriminating between the presence of common cause variation and assignable cause variation. It is a well-established technique, which has shown to be effective in manufacturing processes but not yet in software process contexts. Here experience in using SPC is not mature yet. Therefore a clear understanding of the SPC outcomes still lacks. Although many authors have used it in software, they have not considered the primary differences between manufacturing and software process characteristics. Due to such differences the authors sustain that SPC cannot be adopted "as is" but must be tailored. In this sense, we propose an SPC-based approach that reinterprets SPC, and applies it from a Software Process point of view. The paper validates the approach on industrial project data and shows how it can be successfully used as a decision support tool in software process improvement.

The challenge for software development house in Bangladesh is to find a path of using minimum process rather than CMMI or ISO type gigantic practice and process area. The small and medium size organization in Bangladesh wants to ensure minimum basic Software Process Improvement
(SPI) in day to day operational activities. Perhaps, the basic practices will ensure to realize their company's improvement goals. This paper focuses on the key issues in basic software practices for small and medium size software organizations, who are unable to effort the CMMI, ISO,  ITIL etc. compliance certifications. This research also suggests a basic software process practices model for Bangladesh and it will show the mapping of our suggestions with international best practice. In this IT competitive world for software process improvement, Small and medium size software companies that require collaboration and strengthening to transform their current perspective into inseparable global IT scenario. This research performed some investigations and analysis on some projects’ life cycle, current good practice, effective approach, reality and pain area of practitioners, etc. We did some reasoning, root cause analysis, comparative analysis of various approach, method, practice and justifications of CMMI and real life. We did avoid
reinventing the wheel, where our focus is for minimal practice, which will ensure a dignified
satisfaction between organizations and software customer.

The challenge for software development house in Bangladesh is to find a path of using minimum process rather than CMMI or ISO type gigantic practice and process area. The small and medium size organization in Bangladesh wants to ensure minimum basic Software Process Improvement (SPI) in day to day operational activities. Perhaps, the basic practices will ensure to realize their company's improvement goals. This paper focuses on the key issues in basic software practices for small and medium size software organizations, who are unable to effort the CMMI, ISO, ITIL etc. compliance certifications. This research also suggests a basic software process practices model for Bangladesh and it will show the mapping of our suggestions with international best practice. In this IT
competitive world for software process improvement, Small and
medium size software companies that require collaboration and
strengthening to transform their current perspective into inseparable
global IT scenario. This research performed some investigations and
analysis on some projects’ life cycle, current good practice, effective
approach, reality and pain area of practitioners, etc. We did some
reasoning, root cause analysis, comparative analysis of various
approach, method, practice and justifications of CMMI and real life.
We did avoid reinventing the wheel, where our focus is for minimal
practice, which will ensure a dignified satisfaction between
organizations and software customer.

Bangladesh is now a growing country in ICT industry. Software service industry has come a long way in  the last few decades. The software industry is not only contributing significantly to the national income, but it also has been playing a very crucial role in creating quality employment for a sizable portion of young graduates and automate the operations of business needs.  One of the most encouraging recent trends in the software industry is the leverage on recent positive changes like process practice in day to day operations. Acquire best practice in a small and medium size software house, beside large organizations. Some of these
ventures have done quite well in terms of software delivery using the best practices like CMMI, ISO, ITIL, etc. The small and medium software organizations, however, feel the necessity of process practice to standardize their day to day operations to satisfy valuable customers and benefit their own organizations and transfer knowledge to  new resources in an effective way. 
In order to ensure the minimum best practice in small and
medium software organizations, rather than compliance of
huge practice and sub practice like CMMI, we performed some
investigations and analysis on some projects’ life cycle, current
good practice, effective approach, reality and pain area of
practitioners, etc. We did some reasoning, root cause analysis,
comparative analysis of various approach, method, practice
and justifications of CMMI and real life. We did avoid 
reinventing the wheel, where  our focus is for minimal practice,
which will ensure a dignified satisfaction between
organizations and software customer.

In the highly regulated landscape of medical device development, the Requirements Traceability Matrix (RTM) stands as a cornerstone of regulatory compliance and product safety. For decades, the RTM has been the primary mechanism for demonstrating that every design input is accounted for in the final product and that every safety requirement has been rigorously verified and validated. However, as medical devices increasingly rely on complex software and iterative development cycles, the traditional manual approach to maintaining an RTM has become a significant bottleneck. This whitepaper explores the transformative potential of Artificial Intelligence (AI) in automating the RTM process, shifting it from a labor-intensive compliance burden to a high-performance benchmark for engineering excellence.

Automotive SPICE is used in the automotive industry to comply with functional safety. This guideline uses the waterfall/v-cycle model for software development. However, automotive companies are shifting their way of working into iterative software production using agile methodologies. One of the remaining challenges that persists when combining these two development methodologies is ensuring the critical-safety of the work products with their corresponding documentation, as the Scaled Agile Frameworks (SAFe) used in large companies do not consider this. Therefore, this study takes a deeper look into the software processes of the Aurora team at Volvo Cars ART steering department to propose a new document management strategy that allows the combination of agile software development while still complying with A-SPICE. To achieve this, active observations and interviews were conducted for data collection. The creation of the adapted document management strategy shows that it is possible...

For 25 years the NASA/GSFC Software Engineering Laboratory (SEL) has been a major resource in software process improvement activities. But due to a changing climate at NASA, agency reorganization, and budget cuts, the SEL has lost much of its impact. In this paper we describe the history of the SEL and give some lessons learned on what we did right, what we did wrong, and what others can learn from our experiences. We briefly describe the research that was conducted by the SEL, describe how we evolved our understanding of software process improvement, and provide a set of lessons learned and hypotheses that should enable future groups to learn from and improve on our quarter century of experiences.

Little theory exists in the field of software system measurement. Concepts such as complexity, coupling, cohesion or even size are very often subject to interpretation and appear to have inconsistent definitions in the literature. As a consequence, there is little guidance provided to the analyst attempting to define proper measures for specific problems. Many controversies in the literature are simply misunderstandings and stem from the fact that some people talk about different measurement concepts under the same label (complexity is the most common case). There is a need to define unambiguously the most important measurement concepts used in the measurement of software products. One way of doing so is to define precisely what mathematical properties characterize these concepts, regardless of the specific software artifacts to which these concepts are applied. Such a mathematical framework could generate a consensus in the software engineering community and provide a means for better communication among researchers, better guidelines for analysts, and better evaluation methods for commercial static analyzers for practitioners. In this paper, we propose a mathematical framework which is generic, because it is not specific to any particular software artifact, and rigorous, because it is based on precise mathematical concepts. This framework defines several important measurement concepts (size, length, complexity, cohesion, coupling). It does not intend to be complete or fully objective; other frameworks could have been proposed and different choices could have been made. However, we believe that the formalisms and properties we introduce are convenient and intuitive. In addition, we have reviewed the literature on this subject and compared it with our work. This framework contributes constructively to a firmer theoretical ground of software measurement.

At the moment is important to have got a set of metrics which measures the improvements brought in by efforts to make software processes better. It is often the case that these improvements are measured using informal and subjective processes based on the perception of employees and/or auditors. Bearing all this in mind, this work presents a set of measurements for gauging the performance and capability of software processes, based on the international standard ISO/IEC 15504. This set of metrics aims to lower the level of subjectivity of people when measuring the processes. A more objective and hence more formal evaluation is thus achieved. Actualmente es importante tener un conjunto de medidas para medir las mejoras introducidas por esfuerzos de mejora de procesos de software y que en muchas ocasiones estas mejoras se miden a través de procesos informales y subjetivos basados en la percepción de los empleados y/o auditores. En este trabajo se presenta un conjunto de medidas para medir el rendimiento 1 y la capacidad de los procesos software basados en el estándar internacional ISO/IEC 15504. Este conjunto de medidas tienen como objetivo disminuir la subjetividad de las personas al hacer la medición de procesos, de tal manera que permita realizar la evaluación de manera más formal y objetiva.

This version may not include final proof corrections and does not include published layout or pagination. Citation for the version of the work held in 'OpenAIR@RGU': ALLISON, I., 2005. Towards an agile approach to software process improvement: addressing the changing needs of software products.

Software Process Improvement (SPI) programs are frequently considered to be planned in nature. However, there is recent evidence to suggest that SPI can be understood as a form of learning. Drawing on the organizational learning literature, this paper proposes an active learning perspective of improvements in processes. This view recognizes the various actors in the project to be reflective in their actions, making sense of the current context and thus designing their use of the process to best suit their needs at the time. The changes in the processes emerge through ongoing adjustments, experimentation and improvisation as developers and managers seek to improve their product development.

Software Process Improvement (SPI) programs are frequently considered to be planned in nature. However, there is recent evidence to suggest that SPI can be understood as a form of learning. Drawing on the organizational learning literature this paper proposes an active learning perspective of improvements in processes. This view recognizes the various actors in the project to be reflective in their actions, making sense of the current context and thus designing their use of the process to best suit their needs at the time. The changes in the processes emerge through ongoing adjustments, experimentation and improvisation as developers and managers seek to improve their product development.

This thesis differs from the technological perspective of SPI by identifying and analysing the organisational features of process improvement. A theoretical understanding is developed of how and why software process improvements occur and what are the consequences of the change process within a specific case. A packaged information systems organisation forms the basis for a substantive case study. Adding to the growing body of qualitative research, the study takes a critical hermeneutic perspective. In doing so it overcomes some of the criticisms of the interpretive studies especially the need for the research to be reflexive in nature. By looking at SPI as an emergent rather than deterministic activity, the design and action of the change process are shown to be intertwined and shaped by their context. This understanding is based upon a structurational perspective that highlights how the process improvements are enabled and constrained by their context. The work builds on the recent recognition that the improvements can be understood from an organisational learning perspective. Fresh insights to the improvement process are developed by recognising the role of the individual to facilitate or resist the improvement. The understanding gained here can be applied by organisations to enable them to improve the effectiveness of their SPI programmes, and so improve the quality of their software. Lessons are derived that show how software organisations can support the ongoing improvement through recognition of the learning and political aspects of the change by adopting an agile approach to SPI. viii From this discussion suggestions are made for the management of future SPI projects in Chapter 6. The model developed, however, is not another prescriptive model to he followed in a step by step approach, but shows the features that IS management need to consider to support their improvement initiatives. In the conclusions, lessons and findings are drawn together so that they can be applied more generally in other cases. The research approach adopted is critiqued so as to infi rrn the research methods literature. Suggestions are made for future research of process improvement. "Three proposals are made: one in the area of continuing the study of software package 12 organisations, one in exploring further the political aspects OF SPI, and one in the relationship between education and practice of Sill.