Software Engineering with an Agile Development Framework/Preface/Development History

Arriving at an agile framework for teaching software engineering

Abstract This paper describes the pathway by which have arrived at teaching a particular combination of agile and structured methodologies in a software engineering course within a vocational computing degree. The background of teaching to a pure structured approach is followed by descriptions of eight iterations of increasing agility. The current approach: the “agile framework” is introduced and described.

Keywords: capstone projects, computer education, value proposition

1 Introduction Teaching software engineering at undergraduate level poses the challenge of presenting a robust discipline to students while reflecting industry currency, as software engineering methodologies have been continuously evolving since inception. The recent emergence of the agile methodologies is a significant shift away from established software engineering practices. This has created what Booch (2004) calls “method wars”. The pathway of an institution as picks its way though this battlefield is of interest because it provides a model for considering how the next changes, as yet unforeseen, might be incorporated. In this paper we describe a case study, that of the authors’ pathway in arriving at an ‘agile framework’. The authors’ problem was to determine a framework for introducing agile development within the course without losing the benefits of the structured approach that had been successfully taught over the past six years. Despite the military analogy used by Booch (2004), this pathway is seen as an evolution rather than a revolution. In the following sections we first examine the requirements for a methodology for teaching. We then describe the evolution of the teaching methodology employed.

2 Requirements of a methodology for teaching software engineering Boehm (2004) describes the conflict between plan driven or predictive methodologies and the agile approach and states that “successful, sustainable software development requires both discipline and agility”. In industry, being able to adapt quickly to change can give an organisation the cutting edge over competitors, by reducing time to market and better meeting client requirements. However, to ensure software systems are robust, it is essential that the development is based on sound, disciplined practices. In adopting an agile approach, developers need to be careful not to throw the baby out with the bathwater. Traditional methods, while often held up as a key factor in disastrous software engineering project failures (Standish 1994) have been successfully used in projects for more than 40 years. Agile methods are also continually evolving as more developers apply the principles in new contexts. In fact, Conboy (2004), asserts that “there is no universally accepted definition of an agile method in the field of Information Systems Development”. Noble, Marshall, Marshall, & Biddle (2004) note that the shift to an agile approach in industry “has created a need for a similar shift in software engineering education”, explaining that “document centric project methodologies do not align well with students’ reasonable expectations of more agile working methods”. The issue then, is not how to teach agile or even how to introduce agile elements into the course (Keefe & Dick, 2004) but to present a coherent model for teaching the ‘middle ground’ as a sustainable approach to software engineering education and to prepare them for the capstone project. In providing the students with a coherent range of techniques for software development, they are then well prepared to apply the appropriate strategy in their capstone projects and in the workforce. Boehm (2004) quotes Phillippe Kruchten, architect of the Rational Unified Process, as likening CMM for Software to a dictionary –in making the desired point “there is no need to use all the words available” (p23). Similarly, a robust framework presenting the middle ground of software engineering can incorporate methodologies from both agile and plan driven approaches, along with strategies for selecting the appropriate tools for the job at hand. What are the requirements for a robust methodology for teaching software engineering? It should incorporate a real-life client to mirror an industry experience. It should be flexible (to demonstrate adaptability to change, both in the project and in teaching). It should have a user focus – rather than a plan focussed approach, and it should be applicable over a wide variety of projects, including hardware and network based projects. 2.1 The Agile Model In 2001, a group of developers met in Snowbird, Utah to discuss the state of software development. They had, by various paths, come to the same conclusion - that software quality could be improved by the use of ‘light’ methodologies, with an emphasis on communication, simplicity and embracing change. At this meeting, the term “Agile Method” was coined, and a radically new approach to software development was launched. (Smits, 2005). These developers, including Kent Beck (Extreme Programming) and Ken Schwaber (Scrum Methodology) formed the Agile Alliance, which was dedicated to the promotion of the agile approach. They formulated the shared values of the agile movement. Agility implies • individuals and iterations over processes and tasks • working software over comprehensive documentation • customer collaboration over contract negotiation • responding to change over following a plan. 3 Case study of our evolution In reviews of the 1999 capstone projects and in assessing the 1998 projects we felt that students weren’t getting enough structure and the process was being treated as a game (this itself was a decision by the previous lecturer to follow a simulation based experiential model). The IT205 course is one semester at second year and is a compulsory pre-requisite for the capstone project. We decided to adopt a strategy of making it real: “real projects for real clients” and to follow an “empowerment” approach (Robinson 1994). These decisions were influenced by papers at the time describing the needs of the New Economy and others describing the importance of the student experience. We aimed to create an educational environment or culture that would enable students to move into the New Economy. This entailed a change in approach to one where the focus was on student empowerment. This empowerment was multifaceted – the course handout was presented as a draft; the course content was changed according to needs of the project and students; the students managed the relationship with the client, projects were self assessed and so on. The other change was to adopt a real project for a real client, in that year a ship safety system for an Offshore Master (Mann & Buissink-Smith, 2000). The structure of the course was a strict adherence to a seven stage document-centred Software Development Life Cycle (SDLC) as described by Hoffer, Valacich & George (2004). The course did not include implementation, as it was felt that the students would be better focussed on the best development if they were not hampered by the knowledge (worry?) that they would have build what they designed. The approach taken in this and subsequent years was to attempt to expose students to ‘real world’ situations, while maintaining a positive and constructive learning environment. Within the bounds of the academic environment and staying true to the SDLC, we endeavoured to replicate “real world experiences”. In 2001, we enforced a project swap on project groups (Smith, Mann & Buissink-Smith, 2001). A “run over by a bus” (ROBAB) scenario was repeatedly used in class to emphasise to the students the importance of project documentation. At the end of the Analysis phase, some groups were required to swap their project documentation and continue with the new project and documentation. For some students the effect of this was catastrophic. One student responded with a dramatic outburst shouting as he slammed the door: “I came here to learn and excel, not be dealing with other people’s xxxx”, but most quietly accepted the revision and began to plan their next course of action. In this instantiation, the students benefited from the heavyweight structure. A student comment reported in Smith et al. (2001) seems particularly interesting in hindsight:

“It was important to keep in mind that the process seemed more important than the final product.” (SF)

At the time we interpreted this as ‘we were focussed on learning the process’, but in hindsight we wonder if the process was dominating, ie they were learning SDLC rather than software engineering or perhaps focussing on the client’s product development? At first glance the swapping process would appear to be in conflict with the concepts of empowerment. Most of the concepts of empowerment have been at least dented by the bus crash – in particular are issues of ownership of the process, choices and possibly even “perpetrators and victims of discipline”. The empowerment model, however, does not say that the teacher cannot challenge the students, indeed the model describes students who are “actively engaged in meaningful experiences that the teacher facilitates”. For a while our software-engineering students perceived they had no control, but soon realised they could do it, this, is in a large part due to the stability and framework offered by the SDLC. The students who swapped thought we should repeat the exercise. So, while the locus of control dislocates for a time, it quickly returns and the overall feeling toward the course was positive. In subsequent years the use of real clients and projects in software engineering has continued (Mann & Smith, 2004, 2005). Students undertake a development for these clients, following a prescribed SDLC development process (with increasing agility), accompanied by theoretical instruction. The intention is that the students experience the scope of software engineering with all the implicit difficulties: client issues; complexity of business systems and group work. The increasing agility has been threefold. First we have seen an increasing importance of prototyping and user centred design. The second factor is the evolution of the SDLC in the primary text Hoffer et al (2005). While the first edition gives a seven stage SDLC, by the third it is a five stage model and in the 4th edition it is actually drawn as a cycle. The third factor in increasing agility has come about through an increasingly varied selection of clients. Our approach has been one of teaching the whole SDLC, but focussing on those aspects required for that particular client project. For example, a development of learning and motivation software was prompted by a desire to introduce a project that was much undefined and had more potential for creative work than previous data driven systems. This was a perfect exercise for teaching the importance of early stages of development, the client had little idea of what he wanted, he only recognised that he would benefit from exploring such developments to “be a global player and have more free time”. It also was good in highlighting to students the value of SDLC stages in progressing the project. This project excited students but as it progressed they found it frustrating as it was so ill-defined. An animal ethics management system was chosen in response to the open ended Motivation project – we wanted a project that was tightly defined. The student groups worked with a client from a crown research institute to develop an animal tracking and ethical approval system. This was to integrate with existing systems. This development suited the scope of the SDLC and was ideal for the data analysis phases as there was much extant processes and information: In some cases, the structure imposed by the SDLC gave the students the wrong message, one of deterministic development. A tightly scoped development of generic software with three clients (a Job management system for small engineering businesses) resulted in multiple outcomes according to the client was not appreciated by the students:

“why are there so many different outcomes to the same problem…I felt the lecturers let down the process by not doing enough homework on what was going to result…shouldn’t the lecturers have get a tighter reign” (SF)

Our comments at the time: “it was interesting to see the groups using the SDLC to create some order from chaos…we need to make it clear that students are marked on ability to demonstrate the process, not on actual outcome”. (LecNotes) Other software engineering projects have included a student management system project which was interesting as the students initially thought it too small but in reality is, of course, a huge undertaking. This realisation was drawn out by the development process. It became a challenging project. A client from the maritime museum came to us saying that he wanted a webpage. We could immediately see that there was much more to his needs than that. This task appealed as it turned out to be much bigger than students’ initial understanding. The complexity of museum data, the integration of many existing systems, and the potential for multiple directions meant that very quickly the students realised that without a firm development methodology they would be swimming. In 2003 we were able to produce guidelines for the selection of software engineering projects. In addition to being real, exciting and interesting, we stated that the project should “facilitate teaching the structure of the chosen methodology (SDLC, especially each stage, milestones). For early stage developments the client should have an idea of a business problem, but not a solution…facilitate teaching each of the methodologies’ (SDLC) range of tools and techniques. The more creative projects are better for logical design work but are difficult to apply to data modelling”. In 2005 we investigated the relationship between project methodology, the scale of the project, and student learning. The value of a formal methodology is emphasised by a large and complex project can lead to good outcomes, emphasizing the role of in providing a pathway: “When we first looked at the brief for Captain Black we thought that the scope for the project had the potential to be much larger than anything we could confidently develop” (SF) This, though, can have a disempowering effect, a potentially huge project was clearly not feasible and students lost interest, poor groups scoping this project very small, to the extent of developing little more than login systems. At the other end of the scale, a very small project can further shrink as students lose interest as a result of feeling that the SDLC process is overkill. In the middle of this are tasks that turn out to be much bigger than students’ initial understanding. In an experiment in 2004 (Mann & Smith, 2005) separate streams were presented with different projects of differing technical scope. While the intention was that the differences were in size, the actual differences in project were in the ability of the client to specify their business problem. Again, the structure of the SDLC gave the students a framework within which to tackle the problem:

“At the onset I had no clue of being able to do what was required, so I didn’t have a preconception about what it would look like.  I did not think we could do it and definitely not me.  Now I see it can be done…” (SF)

Unfortunately, the vagaries of the second problem were not overcome by the structure. Instead students went through the motions, often providing meaningless statements. “Due to additional requirements needed by VideoShop regarding their current video rental system, an opportunity has arisen to develop a new enhanced system which will meet these requirements. The current system lacks features required by management and staff to progress financially in the business” (SW). Neither set of groups responded to the opportunity for consideration of complex interactions, even the strongest groups only touched the surface of the areas we had identified as complex. We have then, an evolution of a model that, while based on the SDLC, has seen increasing flexibility. The underlying framework has several advantages. It has provided a base process to return to when things go wrong, it lays out a clear pathway for development and has predictability for teaching. In parallel to the ongoing development of software engineering are the developments of the industry or capstone project itself. Following on from our software engineering course, it is not surprising that students describe as their chosen methodology an ‘SDLC mixed with prototyping’. The issue of what such a description might imply goes beyond computer education: both the scientific and trade literature widely cover issues of prototypes (fidelity, evolutionary/revolutionary etc) but a model for the successful integration remains elusive. Hakim and Spitzer (2000) argued that the “challenge is to systematically incorporate prototypes into the software design and development lifecycle”. In 2003 we aimed to explore the role of development methodology in successful capstone projects, in particular the extent, nature and integration of prototyping (Mann & Smith, 2004). By examining the characteristics of exemplar projects we described a development framework and then verified this model by using it to describe a larger corpora of projects. These we distilled into an exemplar development framework. 1. “SDLC” identified methodology 2. Prototyping used 3. Strong functional requirements used 4. Functional requirements tested with low fidelity but high interactivity prototypes 5. Stable platform for development developed early 6. Prototypes part of integrated testing plan 7. Early functional deliverable to client 8. Robust final deliverable 9. Still need ‘normal’ design – prototyping doesn’t replace 10. Prototypes used in communication with client 11. Maturation by revolutionary (cf evolutionary). Staged replacement for hardware. A side finding in Mann & Smith (2004) was that despite a prescribed document-centric process, there was only a weak relationship between the pages of documentation and assessed grade. We also found that poorer groups did less prototyping, which is understandable; they did less of other things too. What is critical is that when they did prototyping they did not also do “normal design” nor have stable systems, early delivery etc. Poorer groups that used prototypes in early stages also had very weak functional requirements, did not have strong testing plans etc, in other words the prototype became the development in total. Groups in the middle ranges that did prototypes tended to have weaker logical and physical design, instead they saw the development as one of making the prototype robust. In 2004 we were able to conclude that “the tension between product and process can be lessened by adopting a process that can be seen to produce good products while being flexible and robust. We believe that the development framework described here will provide a foundation for capstone courses”. In 2004 this development framework was made compulsory for all capstone projects (Mann & Smith, 2005) to great success. The results showed that project groups did follow the framework and significant increase in the average grade with a reduction in the failing grades. Again, the relationships of parameters within the framework shows that for weaker groups the incremental traditional SDLC process does not sit well with an early development model. In implementing the framework the following instructions were given: We require that you follow the SDLC under an umbrella of Agile Software Development. This gives the benefits of the structure of SDLC while adding flexibility of agile development. The focus of the project is on the production of robust working systems (software, hardware and maintenance documentation). Planning, comprehensive development documentation and processes are important but are 'means to an end' with a focus on content rather than format/representation. It is expected that you discard most of the models you develop (although you do have to keep them for assessment!). We also put emphasis on prototyping and testing. We are going through the SDLC twice. The first iteration is to analyse and design and release (usually to the client) a system that meets most of the functional requirements. The second iteration is intended to review the success of the first iteration in meeting business requirements, to review functional requirements (there will probably be more), and to deliver a stylish "bullet proof" implementation. To enforce framework components such as early deliverables, the following milestones were set: You are required to have at least four significant deliveries of system. 1. Requirements prototype. At the end of the analysis stage. This is a prototype aimed to test functional requirements. 2. Stable platform (week 12). The platform for your system should be developed and tested. For example, for a database with a web front end we would expect you to demonstrate connectivity and basic database functions via the web (insert, delete, query, update) plus any standard infrastructure (login etc). 3. Major release 1, week 25. Deliver to the client a system that meets most of their needs. This system should be usable and stable. 4. Major release 2, week 42. Deliver to the client a production system that meets all of their needs. Although the overall pattern was clearly one of improved grades, the weaker groups, again, demonstrated confusion over the relationships between aspects of agile methodology and the traditional processes. These groups can be characterised as either developing a prototype and initially testing it, but this becomes the project, the subsequent robust development is poor, or are poor at incorporating early development and testing into SDLC. 3.1 Summary of evolution to date The methodology used was primarily Systems Development Life Cycle (based on Hoffer et al, 2004) but had evolved over the six years of teaching the course. The limitations of existing system were that it had become documentation heavy and provided limited access to the client. In addition, students were writing requirements early before they really knew what the client wanted. As the project was not implemented, students moving into the capstone project had little experience of the implementation issues and often failed to produce the required outcomes. By 2005, the taught methodology had evolved to a modified SDLC but with an agile “umbrella” – recognising the importance of embracing change throughout the process. An ethical risk management approach has been introduced using the SoDIS tool, and a usability focus applied in design. The taught methodology in second year could be described as a lose SDLC with a heavy emphasis on prototyping and with a strong user focus but with out considering implementation. The capstone project, meanwhile, was a “twice through the SDLC” also with focus on prototyping where the emphasis in assessment was on implementation and deployment. Many agile methods were actively encouraged (especially scrum meetings, pair programming, test based development, user involvement). 4 Agile framework approach Described here is a development framework that incorporates agile development approaches in a structured framework. The focus of the project is on the production of robust working systems (software, hardware and maintenance documentation). Planning, comprehensive development documentation and processes are important but are 'means to an end' with a focus on content rather than format/representation. It is expected that students discard most of the models they develop, although they do have to keep them for assessment, this we describe as an evidence portfolio. The emphasis is on evidence of a rational process so we encourage time spent annotating diagrams rather than tidying them for presentation. Any development methodology can be seen as a process of reducing uncertainty. At the beginning, we have only an idea, or a business problem to address, there are a great many uncertainties. At the end we have a functional system. The pressures affecting the level of uncertainty at any one time can be seen as interacting streams of work (Figure 1 and 2).

Figure 1: Pressures affecting uncertainty. 
 

Figure 2: Five interacting streams of work.

Figure 3: Sectors of importance of different aspects The varying proportions of each stream coalesce into “sectors” defined by a deliverable output, steering and communication with the client (Figure 3). The sectors here can be seen to resemble a structured development process but crucially, allow for a flexible pathway according to project needs. For both Software Engineering and the Capstone Project we use three iterations (Figure 4). The first iteration is aimed at building understanding within the development group and client. The second iteration is aimed at designing and releasing (to the client) a system that meets many of the functional requirements. The third iteration, “robust delivery” is intended to review the success of the second iteration in meeting business requirements, to review functional requirements (there will probably be more), and to deliver a robust and stylish “bullet proof” implementation.

Figure 4: Three iterations. At any one time, then students are working in a sector made up of the five work streams, being one of three iterations and having a focus on a particular area. Each sector is defined by what it produces (Table 1). Although we aim to provide students with a suite of tools that may be used within each sector, so long as they can provide evidence of a rational process (see evidence portfolio below), we are less concerned with the internals of the sector. Sector diagrams are used to illustrate position on development framework and flow of information (Figure 5). This is the crux of our approach in mixing structure and agility. Students are encouraged to adapt these diagrams meaning that they don’t have to complete every task suggested, so long as they can show that there has been a rational process of getting from the input to the output (petri net concepts have been useful here). In the second iteration we are covering the tools and techniques with only an agile leaning, in the third iteration the focus is the agile techniques. The underlined items in Table 1 form the basis of assessment for the courses. 75% of the marks come from implementation, although, similar to the argument above, this must be backed by “rationale for decisions”. This 75% consists of 10% for stable platform, 15% for 2nd release and 50% for final delivery. The rationale for decisions is given in an evidence portfolio. In addition, client satisfaction is considered a threshold requirement in order to be assessed.

Figure 5: Sector diagrams used to illustrate position on development framework and flow of information (this one for second iteration: design concepts). In the first functional release the emphasis is on getting a useful system to the client. The components in the assessment are timely, rationale for decisions and technical competence. In the final robust delivery, these are joined by quality assurance activities and outcomes; implementation; deployment; technical complexity and client documentation. 5 Conclusion In this paper we have described the pathway we have followed in arriving at an agile framework for teaching software engineering. This approach combines agile and structured methodologies in a way that promotes agility whilst giving an underlying structure for development and teaching. 6 References Beck, K. (2000). Extreme programming explained: Embrace change. New Jersey: Addison Wesley. Boehm, B., & Turner, T. (2004). Balancing agility and discipline, a guide for the perplexed. Boston, MA.: Addison-Wesley. Booch, G. (2004) Foreword. In Boehm, B., & Turner, T. Balancing agility and discipline, a guide for the perplexed. Boston, MA.: Addison-Wesley. Conboy, K., & Fitzgerald, B. (2004). Toward a conceptual framework of agile methods: A study of agility in different disciplines http://doi.Acm.Org/10.1145/1029997.1030005 In Proceedings of the 2004 acm workshop on interdisciplinary software engineering research (pp. 37-44 ). Newport Beach, CA, USA ACM Press. Hakim, J. & Spitzer, T. (2000). Effective prototyping for usability. ACM Special Interest Group for Design of Communications, Proceedings of IEEE professional communication society international professional communication conference and Proceedings of the 18th annual ACM international conference on Computer documentation: technology & teamwork.47-54 Hoffer, J. A., George, J. F., & J. S. Valacich (2004). Modern Systems Analysis and Design. Third Edition. Reading USA, Benjamin Cummings.

Keefe, K., & Dick, M. (2004). Using extreme programming in a capstone project. Paper presented at the Proceedings of the sixth conference on Australian computing education - Volume 30, Dunedin, New Zealand. Noble, J., Marshall, S., Marshall, S., & Biddle, R. (2004). Less extreme programming. Paper presented at the Proceedings of the sixth conference on Australian computing education - Volume 30, Dunedin, New Zealand. Mann, S., & Buissink-Smith, N. (2000). What the Students Learn: Learning through Empowerment. 13th Annual Conference of the National Advisory Committee on Computing Qualifications, Te Papa, Wellington, New Zealand, NACCQ.213-220 www.naccq.ac.nz Mann, S., & Smith, L.G. (2004) Role of the development methodology and prototyping within capstone projects . Proceedings 17th Annual NACCQ, Mann, S. & Clear, T. (eds). Christchurch. July 6-9th 2004. p119-128. Mann S., & Smith, L.G. (2005) Technical complexity of projects in software engineering Proceedings 18th Annual NACCQ, Mann, S. & Clear, T. (eds). Tauranga. July 10-13th July 2005. p249-254 Robinson, H. (1994) The Ethnography of Empowerment: The Transformative Power of Classroom Interaction (Bristol: The Falmer Press). Schwaber, K., Beedle, M. (2002). Agile software development with scrum. New Jersey: Prentice Hall. Smits, H. (2005, 12 March, 2005). What is agile software development? Retrieved 25 August, 2005, from http://www.agilealliance.org/programs/roadmaps/Roadmap/index.htm Standish. (1995). Chaos. Retrieved 1 September, 2005, from http://www.standishgroup.com/ sample_research/PDFpages/chaos1994.pdf Smith, L., Mann, S., & Buissink-Smith, N. (2001). "Crashing a bus full of empowered software engineering students." New Zealand Journal of Applied Computing and Information Technology 5(2): 69-74.

SMITH, L.G., MANN, S. (2004) Projecting Projects: Choosing Software Engineering Projects, Proceedings 17th Annual NACCQ, Mann, S. & Clear, T. (eds). Christchurch. July 6-9th 2004. p183-190. Standish. (1994). Chaos. Retrieved 1 September, 2005, from http://www.standishgroup.com/sample_research/PDFpages/chaos1994.pdf

Iteration 1: Understanding Sector Output

Evaluation Management document (group established, environmental context) Functional requirements Interview with client established Design concepts Ethical design Design specification System metaphor and knowledge base Implementation Conceptual prototype (Release One). Evaluation Proposal to client Iteration 2: Functional delivery in context

	Evaluation	Project estimation

Functional requirements Functional requirements document Design concepts Design concepts presentation Design specification Design specification (style guide etc), Stable development platform: The framework for your system should be developed and tested. Implementation Functional deliverable (Release Two). Deliver to the client a system that meets most of their needs. This system should be usable and stable Evaluation Analysis of functional deliverable Iteration 3: Robust delivery

	Evaluation	Direction for Iteration 3. Complete Ethical processes.

Functional requirements Revisit functional requirements Design concepts Design concepts update, Content production Design specification Style guide, system specification, implementation and deployment plan Implementation Robust delivery (Release Three) Evaluation Project evaluation and completion. Client satisfaction.

Table 1: Required outputs from each sector