Continuous software engineering: A roadmap and agenda

Fitzgerald, Brian; Stol, Klaas-Jan

doi:10.1016/j.jss.2015.06.063

Cited by 499 publications

(443 citation statements)

References 70 publications

Supporting

Mentioning

387

Contrasting

Unclassified

Order By: Relevance

“…Because there was always solution description work going on in the Perform program, the process can be understood as a continuous planning activity involving construction and business. Such continuous planning ensures alignment between the needs of the business and software development (Fitzgerald and Stol 2017). While the programme under study enabled the concept of the on-site customer in practice, further research is needed to better understand the challenge of alignment between the on-site customer representatives and between on-site customer and construction in large-scale projects.…”

Section: Customer Involvementmentioning

confidence: 99%

“…We define large-scale agile development as agile development efforts that involve a large number of actors, a large number of systems and interdependencies (Rolland et al 2016), which have Bmore than two teams^and very large-scale as "agile development efforts with more than ten teams" , These definitions exclude agile methods applied in large organizations (Barlow et al 2011) from Blarge-scale agile^, which we consider to be a research direction on its own. Many refer to this as Benterprise agile^ (Bass 2015;Fitzgerald and Stol 2017).…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation

et al. 2017

View full text Add to dashboard Cite

Agile development methods were believed to best suit small, co-located teams, but the success in small teams has inspired use in large and very large-scale software development. However, fundamental assumptions of agile development are challenged when applying the methods at a very large scale. An interpretative revelatory case study on one of the largest software development programmes in Norway shows how agile methods were adapted and complemented with practices from traditional methods to handle the scale. The programme ran over four years with 12 colocated development teams and a total of 175 people involved. The case study was conducted retrospectively using group interviews with 24 participants and documents. Findings on key challenging areas are reported: customer involvement, software architecture, and inter-team coordination. The revelatory study also suggests refinements of a research agenda for very large-scale agile development. Empir Software Eng (2018) 23:490-520

show abstract

Section: Customer Involvementmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation

et al. 2017

View full text Add to dashboard Cite

show abstract

“…This approach does not just mean testing on agile projects, but testing an application with a plan to learn about it and let the product information and customer feedback guide the testing. Agile testing involves immediately integrating changes into the main system, continuously testing all changes and updating test cases to be able to run a regression test at any time to verify that changes have not broken existing functionality [18,23]. In agile software development, there is a focus on the feature implementation and delivery of value to the customer and, as such, non-functional aspects of a system should also be of attention.…”

Section: Introductionmentioning

confidence: 99%

How is Security Testing Done in Agile Teams? A Cross-Case Analysis of Four Software Teams

Cruzes

Felderer

Oyetoyan

et al. 2017

Lecture Notes in Business Information Processing

View full text Add to dashboard Cite

Abstract. Security testing can broadly be described as (1) the testing of security requirements that concerns confidentiality, integrity, availability, authentication, authorization, nonrepudiation and (2) the testing of the software to validate how much it can withstand an attack. Agile testing involves immediately integrating changes into the main system, continuously testing all changes and updating test cases to be able to run a regression test at any time to verify that changes have not broken existing functionality. Software companies have a challenge to systematically apply security testing in their processes nowadays. There is a lack of guidelines in practice as well as empirical studies in real-world projects on agile security testing; industry in general needs a more systematic approach to security. The findings of this research are not surprising, but at the same time are alarming. The lack of knowledge on security by agile teams in general, the large dependency on incidental pen-testers, and the ignorance in static testing for security are indicators that security testing is highly under addressed and that more efforts should be addressed to security testing in agile teams.

show abstract

“…Embedded and product-intensive software development project teams are becoming increasingly interested in applying practices and tools for continuous software engineering (CSE) [1]; e.g., the Lean Startup method [2], DevOps [3], continuous delivery (CD) [4] and continuous experimentation [5]. Although many of these practices are widely acknowledged in the field of website development [6,7], there are only a few frameworks that describe how CSE can be applied in product-focused embedded system development (e.g.…”

Section: Introductionmentioning

confidence: 99%

“…Fitzgerald and Stol [3] have emphasised continuous integration (CI) between software development and its operational deployment (i.e., DevOps) as well as continuously assessing and improving the link between the business strategy and software development (i.e., BizDev). However, they do not explicitly define how such a business strategy should be carried out or how it is enacted in a continuous manner.…”

Section: Introductionmentioning

confidence: 99%

The CRUSOE Framework: A Holistic Approach to Analysing Prerequisites for Continuous Software Engineering

Karvonen

Suomalainen

Juntunen

et al. 2016

Product-Focused Software Process Improvement

View full text Add to dashboard Cite

Abstract. Continuous software engineering (CSE) is used for customer experiments and repetitive integrated processes within and between business planning and software development. First, this paper defines a new framework, called CRUSOE, for analysing CSE prerequisites. The framework allows for a more precise analysis of the interrelations and estimation of the changes that are prerequisites for moving from traditional product development to CSE. CRUSOE addresses prerequisites associated with and interdependencies among (1) the strategy, (2) architecture and (3) organisation. Second, this paper describes a case study conducted as part of a smartphone platform project to investigate the CSE prerequisites for product-focused software development. The results are synthesised together with recent related studies using the CRUSOE framework. The findings confirm challenges in moving towards CSE in embedded system development. Moreover, context-specific prerequisites should be considered, while it is still unclear as to how CSE can be systematically applied to the non-website development context. Keywords:Continuous software engineering, strategy, architecture, organising, BizDev, software ecosystem IntroductionEmbedded and product-intensive software development project teams are becoming increasingly interested in applying practices and tools for continuous software engineering (CSE) [1]; e.g., the Lean Startup method [2], DevOps [3], continuous delivery (CD) [4] and continuous experimentation [5]. Although many of these practices are widely acknowledged in the field of website development [6,7], there are only a few frameworks that describe how CSE can be applied in product-focused embedded system development (e.g. smartphones, cars etc.). Moreover, there is still very little empirical evidence of the actual usage of these practices in this context. The existing studies have mostly indicated severe challenges in adopting these practices in business-tobusiness (B2B) and embedded system development [8,9,10,11] contexts. In addition, CD and continuous experimentation still seem to mostly be used for small-scale website development projects [6], [8], [12]. Fagerholm et al. [5] have recently investigated continuous experimentation in university software laboratory projects with two case companies and have introduced a model for explaining how the continuous experimentation can be organised. However, more empirical studies are needed to increase our understanding of how these practices could be implemented in different software development contexts. Consequently, in this paper, our goal is to clarify the key prerequisites for applying CSE in product-focused software development.The sustainable success of a company can be linked to its capabilities in terms of bringing new innovations to market. In today's competitive and turbulent business environment, time to market has also become very important. Consequently, business stakeholders have identified rapid fielding and continuous experimentation as important elements of th...

show abstract

Continuous software engineering: A roadmap and agenda

Cited by 499 publications

References 70 publications

Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation

Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation

How is Security Testing Done in Agile Teams? A Cross-Case Analysis of Four Software Teams

The CRUSOE Framework: A Holistic Approach to Analysing Prerequisites for Continuous Software Engineering

Contact Info

Product

Resources

About