Tailoring XP for Large System Mission Critical Software Development

Abstract

Abstract.A plethora of subjective evidence exists to support the use of agile development methods on non-life-critical software projects. Until recently, Extreme Programming and Agile Methods have been sparsely applied to Mission Critical software products. This paper gives some objective evidence, through our experiences, that agile methods can be applied to life critical systems. This paper describes a Large System Mission Critical software project developed using an agile methodology. The paper discusses our development process through some of the key components of Extreme Programming (XP).

Agility from First Principles: Reconstructing the Concept of Agility in Information Systems Development

“…Furthermore, there is evidence to suggest that this lack of cumulative reflection on past research is continuing. For example, in the new body of agile method research, there are many studies documenting how agile methods have been tailored, fragmented, and even combined (e.g., Fitzgerald et al 2006, Aydin et al 2004, Bowers et al 2002, Cao et al 2004, Fenwick 2003). Yet rather than taking the new method variant forward, subsequent researchers inevitably return to "base camp" and relay yet another account of how the original textbook version was tailored or customized.…”

“…Despite this, some argue commercial agile methods are largely restricted to small, co-located development teams, noncritical system development, on-demand access to developers, and many other such constraints (e.g., Stephens and Rosenberg 2003). It must be noted that some vehemently argue that agile methods are applicable in broader contexts, but the sheer volume of research attempting to rebuild and tailor these methods to various environments (e.g., Lindvall et al 2004, Kahkonen 2004, Bowers et al 2002, Cao et al 2004, Crispin and House 2003, Stotts et al 2003, Sarker 2009, Cummings et al 2009) suggests this might not be so simple.…”

“…Rewarding compliance to a commercial agile method might provide an undesirable incentive for developers to adopt a "square peg in a round hole approach," forcing these methods into situations to which they are not suited. An analysis of the literature bears this out, with the vast majority of existing agile method research focusing not on small co-located teams, as was originally intended, but rather on nonstandard implementations, i.e., large teams (Lindvall et al 2004, Kahkonen 2004, Bowers et al 2002, Cao et al 2004, Crispin and House 2003, start-ups (Auer and Miller 2002), distributed development environments , Stotts et al 2003, greenfield sites (Rasmusson 2003), educational environments (Fenwick 2003, Johnson and Caristi 2003, McDowell et al 2003, Melnik and Mauer 2003, Wainer 2003, open source development , outsourcing (Kussmaul et al 2004), and systems maintenance (Poole and Huisman 2001).…”

The Views of Experts on the Current State of Agile Method Tailoring

“…Many efforts have been made to tailor agile methods to suit a variety of contexts such as large teams (Bowers et al 2002;Cao et al 2004;Crispin and House 2003;Kahkonen 2004;Lindvall et al 2004), start-ups (Auer and Miller 2002), distributed development environments Stotts et al 2003), greenfield sites (Rasmusson 2003), educational environments (Johnson and Caristi 2003;McDowell et al 2003;Melnik and Mauer 2003;Wainer 2003), open source development , outsourcing arrangements (Kussmaul et al 2004), and systems maintenance (Poole and Huisman 2001). However, there is little empirical evidence focusing specifically on the extent to which such tailoring is done in a disciplined and educated manner, and it is not known if teams evaluate all practices before deciding whether to adopt each or not.…”

Flexible Working Architectures: Agile Architecting Using PPCs

“…A common belief is that "If you are sufficiently agile, you don't need an architecture -you can always refactor it on the fly". However, it has been argued that an inaccurate architectural design leads to the failure of large software systems and large refactoring might create significant defects [4]. As it is illustrated by Dybá and Dings0yr in [5], several authors advocate that the lack of focus on architecture is bound to engender suboptimal design-decisions.…”