Release Readiness Indicator for Mature Agile and Lean Software Development Projects

Staron, Miroslaw; Meding, Wilhelm; Palm, Klas

doi:10.1007/978-3-642-30350-0_7

Cited by 53 publications

(23 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…[50,47]), a release management workflow [47] or a continuous delivery workflow [46,47] appear also in the literature as enablers of CD. Staron et al [74] present a release readiness indicator, a mechanism to predict in which week the release would be possible given the defect history. In addition, some studies discuss fast release in the context of ASD.…”

Section: Mechanisms For Achieving Fast and Frequent Releasementioning

confidence: 99%

“…Empirical evidence shows that most companies typically perform testing activities late in the development process causing unpredictable additional development efforts [60] and significant delays in releases [74]. Many primary studies emphasise the importance of employing testing and quality assurance (QA) practices throughout the whole development process in the context of CD, as features are rolled out, and not just at the end of the development (e.g.…”

Section: Continuous Testing and Quality Assurancementioning

confidence: 99%

See 1 more Smart Citation

Continuous deployment of software intensive products and services: A systematic mapping study

Rodríguez

Haghighatkhah

Lwakatare

et al. 2017

Journal of Systems and Software

194

153

View full text Add to dashboard Cite

BACKGROUND-The software intensive industry is moving towards the adoption of a value-driven and adaptive real-time business paradigm. The traditional view of software as an item that evolves through releases every few months is being replaced by the continuous evolution of software functionality. OBJECTIVE-This study aims to classify and analyse the literature related to continuous deployment in the software domain in order to scope the phenomenon, provide an overview of the state-of-the-art, investigate the scientific evidence in the reported results and identify areas suitable for further research. METHOD-We conducted a systematic mapping study and classified the continuous deployment literature. The benefits and challenges related to continuous deployment were also analysed. RESULTS-The systematic mapping study includes 50 primary studies published between 2001 and 2014. An in-depth analysis of the primary studies revealed ten recurrent themes that characterize continuous deployment and provide researchers with directions for future work. In addition, a set of benefits and challenges of which practitioners may take advantage were identified. CONCLUSION-Overall, although the topic area is very promising, it is still in its infancy, thus offering a plethora of new opportunities for both researchers and software intensive companies.

show abstract

Section: Mechanisms For Achieving Fast and Frequent Releasementioning

confidence: 99%

Section: Continuous Testing and Quality Assurancementioning

confidence: 99%

Continuous deployment of software intensive products and services: A systematic mapping study

Rodríguez

Haghighatkhah

Lwakatare

et al. 2017

Journal of Systems and Software

194

153

View full text Add to dashboard Cite

show abstract

“…The release readiness prediction, which is an indicator combining measures of the number of defects reports open, number of tests to execute, and a function of test progress. More details on the definition can be found in the work of Staron and Meding Product downtime in field, which is a measure collected from the product log files reported by the customers on regular intervals, combines the measures of time in use and downtime of a product and aggregates that per product line.…”

Section: Measurement Systemsmentioning

confidence: 99%

Industrial experiences from evolving measurement systems into self‐healing systems for improved availability

et al. 2017

Self Cite

View full text Add to dashboard Cite

Automated measurement programs are an efficient way of collecting, processing, and visualizing measures in large software development companies. The number of measurements in these programs is usually large, which is caused by a diversity of the needs of the stakeholders. In this paper, we present the application of the self-healing concepts to assure the availability of measurements to the stakeholders without the need for effort-intensive and costly manual interventions of the operators. We study the measurement infrastructure at one of the development units of a large infrastructure provider. In this paper, we present how the Monitor, Analyze, Plane, and Execute with Knowledge model was instantiated in a simplistic manner to reduce the need for manual intervention in the operation of the measurement systems. Based on the experiences from the 2 cases studied in this paper, we show how an evolution toward self-healing measurement systems is done both with a dedicated failure taxonomy and with an effective straightforward handling of the most common errors in the execution.The mechanisms studied and presented in this paper show that self-healing provides significant improvements to the operation of the measurement program and reduces the need for daily oversight by an operator for the measurement systems.KEYWORDS measurement systems, metrics, self-healing INTRODUCTIONModern software development organizations utilize software measurement to get insight into the performance of their products or efficiency of the organization, which over time leads companies to collect a large amount of measurement data. The growing amount of measurement data leads to a growing effort for maintaining the measurement program. The needs in such large organizations and their evolution entail the need to constantly monitor and repair measurement systems. One of the challenges is to balance the availability of the measurements and with the cost of operating the measurement program. The availability of the measurement systems is required to support the operations of the company and to improve its decisions; the up-to-date information should be available, and if it is not up-to-date, its latest status should be provided and the user (stakeholder) of the information notified.

show abstract

“…Baccelli and Bird [14] investigated the outcomes and challenges of modern tool-based code reviews and observed that, amongst other things, code reviews are not only used for revealing defects, but also serve to promote awareness and knowledge transfer. Slightly related to velocity is the work of Staron et al [15]. They identified the time-to-release as the main indicator for release readiness based on a number of metrics.…”

Section: Related Workmentioning

confidence: 99%

Towards quality gates in continuous delivery and deployment

Schermann

Cito

Leitner

et al. 2016

2016 IEEE 24th International Conference on Program Comprehension (ICPC)

View full text Add to dashboard Cite

Quality gates, steps required to ensure the reliability of code changes, are supposed to increase the confidence stakeholders have in a release. In today's fast paced environments, we have less time to perform the necessary precautions to minimize the risk of a faulty release. This leads to an inherent trade-off between risk of lower release quality and time to market. We provide a model for this tradeoff of release confidence and velocity that led to the formulation of 4 categories (cautious, balanced, problematic, madness), in which companies can be classified in. We showcase real examples of these categories as case studies based on previous empirical studies. We close by presenting possible transitions between categories that guide future research. Towards Quality Gates in Continuous Delivery and DeploymentGerald Schermann, Jürgen Cito, Philipp Leitner, and Harald C. Gall University of Zurich, Department of Informatics, Switzerland {schermann, cito, leitner, gall}@ifi.uzh.chAbstract-Quality gates, steps required to ensure the reliability of code changes, are supposed to increase the confidence stakeholders have in a release. In today's fast paced environments, we have less time to perform the necessary precautions to minimize the risk of a faulty release. This leads to an inherent trade-off between risk of lower release quality and time to market. We provide a model for this trade-off of release "confidence" and "velocity" that led to the formulation of 4 categories (cautious, balanced, problematic, madness), in which companies can be classified in. We showcase real examples of these categories as case studies based on previous empirical studies. We close by presenting possible transitions between categories that guide future research.

show abstract

Release Readiness Indicator for Mature Agile and Lean Software Development Projects

Cited by 53 publications

References 20 publications

Continuous deployment of software intensive products and services: A systematic mapping study

Continuous deployment of software intensive products and services: A systematic mapping study

Industrial experiences from evolving measurement systems into self‐healing systems for improved availability

Towards quality gates in continuous delivery and deployment

Contact Info

Product

Resources

About