Software Process Maturity Research Articles

Business process management approach for improving agile software process and agile maturity

AbstractContinuous improvement of agile software processes is inevitable in order to reach sustainable and high‐quality project outcomes. In this sense, organizations need guidance on how to apply agile software process improvement effectively; comprehensive approaches with in‐depth analysis and guidelines are required to keep software processes in balance and to continuously improve them, as in a typical business process, over time. This research aims to explore the implementation of Business Process Management approach for improving an agile software process and accordingly agile maturity level. Many organizations utilize from Business Process Management approach in order to improve workflows and to discover organization‐specific weaknesses. For this purpose, the study presents a practical, flexible model based on Business Process Management approach for agile software process improvement, which also incorporates maturity assessment for measuring the agile maturity level. Furthermore, an exploratory case study with a triangulation methodology of mixed methods was carried out for implementation of the model. The research puts forward that Business Process Management approach can be used for in‐depth analysis of agile software process, discovery of problems, and redesign of the process. The research roadmap introduces worthwhile insights on agile software process improvement for researchers and practitioners.

Integrating Technical Debt Management and Software Quality Management Processes: A Normative Framework and Field Tests

Despite the increasing awareness of the importance of managing technical debt in software product development, systematic processes for implementing technical debt management in software production have not been readily available. In this paper we report on the development and field tests of a normative process framework that systematically incorporates steps for managing technical debt in commercial software production. The framework integrates processes required for technical debt management with existing software quality management processes prescribed by the project management body of knowledge (PMBOK), and it contributes to the further development of software-specific extensions to the PMBOK. We partnered with three commercial software product development organizations to implement the framework in real-world software production settings. All three organizations, irrespective of their varying software process maturity levels, were able to adopt the proposed framework and integrate the prescribed technical debt management processes with their existing software quality management processes. Our longitudinal observations and case-study interviews indicate that the organizations were able to accrue economic benefits from the adoption and use of the integrated framework.

Successful process improvement projects are no accidents

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.

TOWARDS MATURE SOFTWARE PROCESS

Software process maturity is strongly linked to the success or failure of the projects. It is also closely related with the quality of the products and the efforts necessary to develop them. Soft-ware process improvement and certification is very important for Lithuanian IT companies seeking to increase the export of their software products and services. Public procurement of IT products and services desiderates impartial criteria for supplier selection. This paper provides analysis of current situation in Lithuania and the initiatives taken in the software process improvement area. Special attention is paid for the project performed by Vilnius University, Kaunas University of Technology together with leading Lithuanian IT companies Alna and Sintagma seeking to provide methodology and tools supporting assessment, definition and implementation of mature software process.

The impact of Software Process Maturity on Software Project Performance: The Contingent Role of Software Development Risk

Despite growing efforts to improve software development processes, recurring concerns about software project performance remain largely present. The rate of software development project failure rate has been routinely documented in information systems (IS) research (Wallace, 2004; El-Masry and Rivard, 2010). The management of software development projects is often marked by inadequate planning, a poor grasp of the overall development process, and no clear management framework, even as the focus in software development shifts from a technology perspective to a more process-centric view (Slaughter, 2006). To address such concerns few CMM-based studies have examined the benefits and direct impact of software process maturity on software project performance but with mixed results. The present paper attempts to systematically examine the contingent role of software development risk on the impact of software process maturity level on software project performance. Guided by risk-based perspective in Software Engineering and CMM-based framework, an exploratory model was developed and tested. The premise of this paper is that software development risk plays a contingent role in the relationship between software process maturity and software project performance. Drawing on a sample of 107 organizations that have undergone official CMM appraisals, the results of partial least squares analysis of the data reveal initial evidence that (1) a positive effect of software process maturity level on software project performance while underscoring the negative effect of software development risk on software project performance, and (2) more importantly, the findings show that software development risk plays a contingent role software process maturity level on software project performance. For researchers, the integration of software development risk can provide a much needed linkage in the three fundamental constructs of CMM. From a managerial perspective, in order to foster a better software project performance, IS project leaders and managers should strongly emphasize devising effective software development risk assessment since a variation of this construct’s level may strengthen or weaken the relationship between software development process maturity and software project performance.

The impact of Software Process Maturity on Software Project Performance: The Contingent Role of Software Development Risk

Malgré les efforts croissants déployés pour améliorer les processus de développement des systèmes d’information (SI), la performance des projets d’informatisation demeure un sujet d’actualité dans l’industrie. Le taux d’échec de ces projets a été systématiquement documenté dans la littérature SI. (Wallace, 2004; El-Masry et Rivard, 2010). La gestion des projets de développement des SI est souvent caractérisée par une planification inadéquate, une mauvaise maîtrise du processus de développement global et un cadre de gestion imprécis (Slaughter, 2006). Le présent papier tente d’examiner le rôle modérateur du risque de développement SI sur l’impact du niveau de maturité du processus de développement SI sur la performance du projet. Un modèle basé sur le cadre CMM a été développé et testé. Des résultats révélateurs ont été observés à l’appui d’une enquête empirique effectuée auprès de 107 organisations ainsi que des résultats de l’analyse partielle des moindres carrés des données : (1) un effet positif du niveau de maturité du processus de développement SI sur la performance du projet tout en soulignant l’effet négatif du risque de développement SI sur la performance du projet et (2) le rôle contingent du risque de développement SI dans cette relation.Pour les chercheurs SI, l’intégration du construit risque de développement SI souligne le rôle clé de ce construit dans la conceptualisation CMM. D’un point de vue managérial, pour obtenir une meilleure performance des projets SI, les chefs et gestionnaires de ces projets devraient mettre en œuvre une conception plus efficace d’évaluation des risques de développement SI puisqu’une variation du niveau de ce construit peut renforcer ou affaiblir la relation entre la maturité du processus de développement SI et la performance du projet.

The Influence of Software Process Maturity and Customer Error Reporting on Software Release and Pricing

Software producers are making greater use of customer error reporting to discover defects and improve the quality of their products. We study how software development differences among producers (e.g., varying levels of process maturity) and software class and functionality differences (e.g., operating system versus productivity software) affect how these producers coordinate software release timing and pricing to optimally harness error reporting contributions from users. In settings where prices are fixed, we characterize the optimal release time and demonstrate why in some cases it can actually be preferable to delay release when customer error reporting rates increase. The manner in which a firm's optimal release time responds to increases in software functionality critically hinges on whether the added functionality enhances or dilutes user error reporting; in both cases, the effect of added functionality on release timing can go in either direction, depending on both firm and product market characteristics. For example, when processing costs are relatively large compared with goodwill costs, firms with lower process maturity will release earlier when per-module error reporting contributions become diluted and release later when these contributions become enhanced. We also examine how a firm adapts price with changes in error reporting levels and software functionality, and finally, we provide implications of how beta testing influences release timing. This paper was accepted by Lorin Hitt, information systems.

Process Maturity Analysis of the Bulgarian Enterprises

Abstract The concept of Process Maturity Levels was developed at the Software Engineering Institute (SEI) at Carnegie Mellon University in the Nineties, based on quality work originally undertaken by Watts Humphrey. Originally developed to support the analysis of software process maturity (CMM), the latest version, the Capability Maturity Model Integrated (CMMI) has been generalized so that it can be applied to any of a wide variety of processes in diverse organizations. CMMI defines five levels of process maturity that describe how organizations typically evolve from immature to mature organizations. Organizations at level 1 do not support processes in any significant way and are immature. Level 5 organizations are completely mature and have mastered the use of processes. Most organizations are not, right at one level or another. This report summarizes information provided by 520 respondents who completed Process Maturity Levels Survey between January and September in 2012. This analysis puts lot emphasis on how Bulgarian companies document processes and reveal the evolution of their maturity. The survey shows that most organizations in the Bulgaria are somewhere between Level 1 and Level 2, trying to expand the processes they have modeled and understand into a complete process architecture. Similarly, a smaller group of companies are between Level 3 and 4. They are working to establish process management and measurement systems throughout the company.

A Software Capability Maturity Adoption Model for Small and Medium Enterprises in Developing Countries

AbstractControlling and improving the processes used to develop software has been proposed as a primary remedy to the problems of schedule, over budget and non conformity to requirements in software development. Consequently the software development community has adopted several Software Process Improvement approaches such as the Software Capability Maturity Model published by the SEI as a criterion to evaluate and improve software process maturity. The premise of the Software Capability Maturity Model is that a mature development process will deliver products on time, within budget, requirements and of high quality. Research carried out in developed countries to evaluate the effectiveness of such programmes has confirmed that Software Process Improvement can contribute to the production of high quality software. However, this phenomenon has been less studied in smaller enterprises such as those in Uganda and other developing countries. This study examined the effectiveness of the Software Capability Maturity Model for use in small software developing enterprises and established that the model was difficult to implement in such organizations. Many of its constructs were irrelevant. An adoption model for software capability maturity was designed based on only those factors and constructs of the Software Capability Maturity Model that were found to be relevant to Small and Medium Enterprises. The new model was tested using case study and expert judgment methods. The experts and software developers indicated that the proposed model is more applicable in Small and Medium Enterprises operating in resource constrained countries such as Uganda.

Is employee attitudes and perceptions at varying levels of software process maturity

Taking a control theory view of software process innovation, we tested prevalent beliefs regarding software process maturity and Information Systems employee attitudes and perceptions by surveying 736 IS professionals in 10 organizations at varying levels of the CMM (capability maturity model). Although anecdotal reports and the scant empirical studies to date suggest job attitudes and perceptions are more positive for employees in organizations at higher levels of software process maturity, we found evidence of a more complex picture. While our data supported expectations that role conflict and perceived work overload were lower for IS professionals in organizations at a level of maturity where software process behavioral controls are implemented, other results were not fully in line with prevalent beliefs. Most notably, IS workers reported significantly lower professional efficacy and lower job satisfaction in organizations at CMM Level 3, where behavioral controls are the dominant form of formal control, than in organizations at Level 1, which is relatively free of formal controls. Some anticipated positive attitudes and perceptions surfaced in organizations at the highest rungs of software process maturity (CMM Levels 4/5), where the established behavioral controls are supplemented by substantial outcome controls, as IS professionals reported lower role ambiguity and higher job satisfaction than did their counterparts in organizations at CMM Level 3.

IS Employee Attitudes and Perceptions at Varying Levels of Software Process Maturity

Taking a control theory view of software process innovation, we tested prevalent beliefs regarding software process maturity and Information Systems employee attitudes and perceptions by surveying 736 IS professionals in 10 organizations at varying levels of the CMM (capability maturity model). Although anecdotal reports and the scant empirical studies to date suggest job attitudes and perceptions are more positive for employees in organizations at higher levels of software process maturity, we found evidence of a more complex picture. While our data supported expectations that role conflict and perceived work overload were lower for IS professionals in organizations at a level of maturity where software process behavioral controls are implemented, other results were not fully in line with prevalent beliefs. Most notably, IS workers reported significantly lower professional efficacy and lower job satisfaction in organizations at CMM Level 3, where behavioral controls are the dominant form of formal control, than in organizations at Level 1, which is relatively free of formal controls. Some anticipated positive attitudes and perceptions surfaced in organizations at the highest rungs of software process maturity (CMM Levels 4/5), where the established behavioral controls are supplemented by substantial outcome controls, as IS professionals reported lower role ambiguity and higher job satisfaction than did their counterparts in organizations at CMM Level 3.

The Influence of Software Process Maturity and Customer Error Reporting on Software Release and Pricing

Software producers are making greater use of customer error reporting to discover defects and improve the quality of their products. We study how software development differences among producers (e.g., varying levels of process maturity) and software class and functionality differences (e.g., operating system versus productivity software) affect how these producers coordinate software release timing and pricing to optimally harness error reporting contributions from users. In settings where prices are fixed, we characterize the optimal release time and demonstrate why in some cases it can actually be preferable to delay release when customer error reporting rates increase. The manner in which a firm's optimal release time responds to increases in software functionality critically hinges on whether the added functionality enhances or dilutes user error reporting; in both cases, the effect of added functionality on release timing can go in either direction, depending on both firm and product market characteristics. For example, when processing costs are relatively large compared to goodwill costs, firms with lower process maturity will release earlier when per module error reporting contributions become diluted and release later when these contributions become enhanced. We also examine how a firm adapts price with changes in error reporting levels and software functionality, and finally provide implications of how beta testing influences release timing.

An integrated technology for intelligent software risk management

The paper presents a formalized technology for risk management intellectualized with new functions to increase the software process maturity. Intelligent risk management (IRM) is represented by a double spiral with "inner" turns being the processes of expert assessment of IRM objects to support the increased consistency of decisions and the efficiency of IRM participants. They link "outer" turns (the cycles of efficient risk mitigation in a common information environment at the levels of both developing organization and software project) to support the integration of project targets and improvement of software quality and strategic goals of the executing organization.

Data Warehousing Process Maturity: An Exploratory Study of Factors Influencing User Perceptions

This paper explores the factors influencing perceptions of data warehousing process maturity. Data warehousing, like software development, is a process, which can be expressed in terms of components such as artifacts and workflows. In software engineering, the Capability Maturity Model (CMM) was developed to define different levels of software process maturity. We draw upon the concepts underlying CMM to define different maturity levels for a data warehousing process (DWP). Based on the literature in software development and maturity, we identify a set of features for characterizing the levels of data warehousing process maturity and conduct an exploratory field study to empirically examine if those indeed are factors influencing perceptions of maturity. Our focus in this paper is on managerial perceptions of DWP. The results of this exploratory study indicate that several factors-data quality, alignment of architecture, change management, organizational readiness, and data warehouse size-have an impact on DWP maturity, as perceived by IT professionals. From a practical standpoint, the results provide useful pointers, both managerial and technological, to organizations aspiring to elevate their data warehousing processes to more mature levels. This paper also opens up several areas for future research, including instrument development for assessing DWP maturity

An empirical study of software process maturity, TQM practices and organizational characteristics in Taiwanese companies

In this paper, the authors examine the relationship between TQM-based organizational culture, organizational characteristics, IS department characteristics, and the modified software maturity process (MCMM). The result shows that the use of data, continuous improvement, customer-orientation, and the job challenges are significantly correlated with the MCMM levels. The size of the organization, IS department size, and IS department roles also have impacts on MCMM level.

Applying a framework for the improvement of software process maturity

AbstractThis article presents the results and lessons learned in the application of the Framework for the Modelling and Measurement of Software Processes (FMESP) in a software company dedicated to the development and maintenance of software for information systems. The aim of FMESP is to provide companies with a conceptual and technological framework for the management of their process models and measurement models in an integrated way. Modelling and measurement are two key factors to promote continuous process improvement. As a result, important benefits were obtained. The company improved the maturity of its processes which allowed it to obtain the ISO 9000 certification. From a research point of view, Action‐Research was successfully applied and as a result the framework was improved and important feedback was obtained, bringing to light new important issues which will be tacked in future work. Copyright © 2005 John Wiley & Sons, Ltd.

A longitudinal study of software process management in Taiwan's top companies

Managing the software development process has been an important issue in the IT field. Since the mid-1980s, the Software Engineering Institute (SEI) has been exploring effective ways of managing the software development process. In 1987, SEI proposed a software process maturity framework (Humphrey & Sweet, 1987). Later in 1991, it further announced the capability maturity model (CMM) (Paulk et al. , 1991). Since then, there has been a rapidly growing number of software organizations adopting the CMM as a framework for internal improvement initiatives, including commercial organizations. This study surveys the IT organizations of the top 1000 business companies in Taiwan. It explores the status of software process management (SPM) in these companies and compares the findings with a similar study done in 1996. It further compares the SPM status with Japanese and US data reported in the literature. Finally, it identifies the weaknesses of the surveyed companies and recommends corrective actions for improving their software processes.stated explicitly. This includes the importance of TVM in the Product Development Process, which include the management of time and quality by reducing the overall process cycle. Total quality management is a major part of TVM, which assists in the accomplishment of the tasks of TVM. The concept of accuracy is one of the most important strategies that management can introduce into a shipyard to improve competitiveness. An introduction to the concept of "Zero Defects' versus "Construction Tolerance' is given in this paper. This paper also includes the detailed study of the implementation of TQM in the shipbuilding process with the examples of European and Korean shipyards. Knowledge of these examples reveals the importance of TQM in the shipbuilding process.

Evolution of the frameworks quagmire

Various combinations of national and international standards bodies, government organizations, professional societies, and other quasilegislative bodies, each vying for influence over a particular market sector, have promulgated a dizzying array of software and system process standards, recommended practices, guidelines, maturity models, and other frameworks. The resulting quagmire has quenched the ardor of many organizations seeking accreditation for one or more frameworks. Software and systems engineers question whether the qualification process will lead to quarrels over interpretation rather than quick and real progress. In 1997, the Software Productivity Consortium created a Web site to help organizations understand which frameworks were most important and how they related to each other (http://www.software.org/quagmire). As the paper shows, many new frameworks and updates to existing frameworks have appeared since then. Fortunately, most of these additions recognize the need for compatibility and attempt to define their relationship with other models.

SPI patterns: learning from experience

Thousands of organizations have been improving their software process maturity level since the Capability Maturity Model (CMM) appeared in 1991. Organizations have improved project management, automated configuration management, and introduced reuse practices. Some of them succeeded; others failed. If we could extract lessons for the software community from these experiences, organizations could avoid repeating mistakes. Publications such as the 'Process Maturity Profile of the Software Community' show organizational trends assessed against the SW-CMM, They provide information about the organizations' state and the time spent moving from one level to the other, but say nothing about the different ways used to reach that state. Unfortunately, such information is embedded in experiences that are not public. However, initiatives such as the European Systems and Software Initiative facilitate some of these experiences. The European Commission has been funding around 400 process improvement experiments (PIEs) through ESSI since 1993. More than 250 are public and available through Vasie, a repository that can be accessed through the Internet. Many researchers have analyzed this repository (and the ESSI) many times, but none have focused on identifying patterns of solutions for specific problems or patterns for pursuing concrete business goals, or on determining that pattern's relative success of such patterns. Many disciplines have identified patterns by the analysis of past experiences, and we believe this approach is also valid for software process improvement.

Can you trust software capability evaluations?

In the early 1989s, the US Department of Defense suffered many monetary, schedule, and performance costs because it misjudged the ability of its contractors to develop software. Recognizing that this was less a reflection on the organizations themselves than on the general immaturity of the software industry, the DoD helped create the Software Engineering Institute with the aim of studying ways to help the software industry grow responsibly. In 1987, the SEI established the software capability evaluation (SCE) as a formal way to determine an organization's software process maturity framework and generally measure its software development competence. SCEs are widely used to determine an organization's Capability Maturity Model rating, but their results can be misleading. The authors reveal how certain practices distort results and waste time and money, through intentional contractor vagueness and detail, inappropriate sample projects, and staff coaching. They go on to suggest ways to improve the process.