Session S2C THE AGILE APPROACH IN AN ... - ICEE

Session S2C THE AGILE APPROACH IN AN UNDERGRADUATE SOFTWARE ENGINEERING COURSE PROJECT Thomas Reichlmayr1 Abstract - The rise in popularity of agile software development methodologies such as Extreme Programming (XP), Crystal, DSDM and Feature-Driven Development has opened an opportunity for the software engineering education community. How can one capitalize on the strengths of agile development models while still appealing to established software engineering practices? The typical introductory software engineering course makes use of a team-based project to reinforce software process activities. The project normally runs for one academic term during which students are led through life-cycle activities using a modified waterfall approach to software development. While useful in teaching software engineering process concepts, this approach limits the team’s ability to utilize feedback from downstream process activities. It also limits the students’ opportunity to understand process improvement from their own experiences. The ability to respond to project change is also dampened by the fact that teams do not have the time or resources in this format to modify, or refactor the design of a project component let alone incorporate a new or modified customer requirement. Agile methodologies promote an evolutionary approach to development using short incremental release cycles. We report on the experiences of conducting a team project in an introductory software engineering course using agile development techniques at the Rochester Institute of Technology. Teams have the opportunity to experience multiple iterations of the software engineering life cycle and evolve a product design that allows for discoveries made during implementation and through the introduction of changing customer requirements. The project integrates the concept of testdriven development. This agile technique addresses testing early in the development process and reinforces the value of unit testing. The incorporation of agile techniques is not only useful for students in an introductory course, but may also be applied to upper division software engineering courses. Index Terms – Agile Software Development, Test Driven Development

INTRODUCTION Established in 1996, and becoming one of the first software engineering undergraduate programs in the country to apply for ABET accreditation, the Software Engineering Department of the B. Thomas Golisano College of 1

Computing and Information Sciences at the Rochester Institute of Technology has established a program with a goal of preparing graduates for careers in the software development profession. An educational objective of the program is providing a solid foundation for a student’s life long professional growth. It is during our introductory software engineering course that we have the first opportunity to formally introduce fundamental software engineering principles that will contribute to the continued success of our students throughout the remainder of their academic and future professional careers. In a field as broad and rapidly changing as software engineering selecting the first layer of building material for that foundation becomes a daunting challenge. In determining the breadth and depth of topics to include in an introductory course project, activities need to be constructed that best reinforce the software engineering principles one would identify as composing this foundation layer. Equally important is the need to engage students in activities that stimulate their interest in professional software development. This paper will report on the experience of running a team-based project in our introductory software engineering course that attempts to address these challenges using agile development techniques.

BACKGROUND Software Engineering I (SE361) is the initial course offering in our department’s program. The typical student will take SE361 in the second quarter of their sophomore year. Prior to that they will have completed a sequence of introductory computer science (CS) courses. The CS courses focus on developing programming skills (using Java and C++) and address traditional CS topics – data structures, algorithms, object-oriented concepts and some exposure to concurrent and network programming techniques. Students individually complete lab and project assignments with little opportunity, or need, for collaboration with fellow classmates. The CS course sequence introduces some software engineering concepts, but at a cursory level. For example, students are able to identify the major activities associated with the waterfall life cycle of development. Students arrive to SE361 with accomplished individual programming skills and finegrained problem solving techniques. The course is composed of a lecture section and project lab section. Teams of five to six students form during the first lab session and work together for the remainder of the

Thomas Reichlmayr, Software Engineering Department, Rochester Institute of Technology, Rochester, NY 14623, [email protected]

0-7803-7961-6/03/$17.00 © 2003 IEEE November 5-8, 2003, Boulder, CO 33 rd ASEE/IEEE Frontiers in Education Conference S2C-13

Session S2C quarter. The lab section meets formally for two hours each week. The scope of project activities normally requires teams to meet outside of regular class and lab times. Our department offers SE361 not only for students enrolled in our program, but also as a required course for students in the computer science and computer engineering programs. After completing SE361 software engineering majors will continue on in our curriculum with additional courses in software development process, architecture, design, testing and requirements engineering that expand on the topics introduced in SE361 [1,2]. However, for the computer science and computer engineering students, this course may represent their only formal exposure to software engineering during their undergraduate studies. We would like to have these students walk away from our course with a better understanding and appreciation for the dynamics involved in software product development.

COURSE PROJECT OBJECTIVES In previous versions of this course, projects were undertaken using a plan driven, top-down development approach. Student teams would work their way through the execution of the project paralleling waterfall model development activities – requirements, analysis, design, code, test, and release. At the conclusion of the term, teams would hold a postmortem session as an exercise in identifying areas for process improvement. Since the entire term was required to comp lete one development cycle, there was no opportunity for teams to apply identified process improvements in another cycle. As this was most students’ first experience with design, teams would ultimately discover during the implementation phase that the detailed design decisions made only a few weeks prior were inconsistent with the code now being generated. This accounted for a flurry of activity in the latter part of the term that represented an unequal amount of effort relative to the development activities performed earlier in the term. As teams scrambled to meet the delivery date for their product students perceived earlier project artifacts as less relevant and formal testing activities received less attention due to schedule pressures. Students resorted to the survival skills that had gotten them through previous programming courses – they attempted to code their way to project completion. Early project activities were often viewed as merely slowing down the code generation process. Similar experiences have been reported with older students during capstone projects [15]. In the redesign of the project component of SE361 we recognized the need to incorporate multiple product deliveries in order to provide students with an opportunity to apply process improvement initiatives. We also needed to include activities that better illustrated fundamental software engineering skills not grasped by students in previous versions of the course. Many of these skills encompass the process related topics that are difficult to impress on students with limited software development experience and within

the abbreviated course timeframe. Industry surveys have identified “knowledge gaps” between what is learned in education and the topic’s importance in an industrial environment [10]. Skills commonplace in a project setting such as configuration management, release planning, maintenance, testing and reengineering are normally acquired via on-the-job experience as opposed to learned during academic studies. In examining our objectives for the redesigned project course the following opportunities were identified. Project Planning Teams should be exposed to basic project planning skills using lightweight estimation and scheduling techniques. Planning is determined along functional ilne items per a given release cycle as opposed to software development life cycle activities. Teams are required to track progress and develop strategies for addressing project risks. A focused set of metrics is collected for use in reflection and postmortem activities for identifying process improvement initiatives. Development Environment Prior to SE361 students had developed software projects in previous courses primarily with a standard text editor or language sensitive editing tool like Emacs 2 . To promote working in a team oriented, collaborative environment the use of an integrated development environment (IDE) is a necessity. The tools used should support the team’s development effort, not be the focus of their effort. Testing The knowledge gap that exists in activities related to testing is disproportionately larger than any of the fundamental software engineering skills we were addressing in our course goals. Testing may easily consume 50% of the resources for a typical software development project, yet the typical undergraduate computing curriculum devotes far less a percentage of time and effort to testing or verification and validation topics [13]. Design An important component of our program is a focus on the area of software architecture and design. As this course is a student’s first exposure to design in the large, activities should be structured to allow the team to quickly establish a preliminary design for the project that has the ability to evolve and change throughout the project’s life cycle. In the past, inexperienced student teams have struggled envisioning the complete system design using a top-down approach to product development. Students would benefit more from evolving an increasingly complex design incrementally in order to be able to study the effect of design decisions on subsequent implementation activities.

2

http://www.gnu.org/software/emacs


Session S2C AGILE PRACTICES IN EDUCATION Although agile practices have received substantial attention in recent years, agile methodologies have roots in the early to mid 1990’s with Scrum and Dynamic Systems Development Methodology (DSDM) [12]. Indeed certain qualities one may associate exclusively with agile methodologies such as incremental development have been part of traditional approaches to software development over the past thirty years. The advent of Extreme Programming or XP in the late 1990’s has been acknowledged as a common starting period for several of the more widely known versions of agile methodologies – Crystal Methods, Feature-Driven Development (FDD) and Adaptive Software Development, in addition to the continued usage of the methodologies referenced above [12]. Previous experience accounts of agile techniques in the classroom are concentrated in the area of extreme programming [3,6,11] and pair programming [16]. When putting together our course project, an approach was taken to incorporate those agile practices that would best complement the course’s objectives and illustrate fundamental software engineering skills - not necessarily following the letter of a single methodology. The principles of agile development that looked most promising for our objectives were the following subset of the Manifesto for Agile Development principles [14]: • • • • • •

Deliver working software frequently The most efficient and effective method of conveying information within a development team is face-to-face conversation. Working software is the primary measure of progress. Continuous attention to technical excellence and good design enhances agility. Simplicity – the art of maximizing work not done – is essential. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The combination of applying these principles along with the incorporation of traditional software engineering techniques in requirements elicitation, analysis, design and testing formed a hybrid approach to process that has been advocated by previous software engineering course implementations using agile techniques [5,6,8].

PROJECT EXPERIENCES One of the more interesting aspects of putting together a course project is selecting the problem domain. Having seen our fair share of course scheduling and video rental applications we strived to identify a more unique domain area. The selection of the application to build is also influenced by the amount of domain expertise required by

the students to facilitate the knowledge transfer of the problem’s requirements into a software solution. Inspired by Martin’s account of developing a solution to score a game of bowling using test first design [14], we chose to build an automated bowling alley management system. This application is one that is familiar to most students, yet contained enough unknowns to offer a fair opportunity for some requirement elicitation activity. For example, few students were familiar with the algorithm used for scoring a bowling game. Project Schedule The course project schedule is shown in Table I. Note that RIT is on the quarter system, which leaves us only a short eleven weeks to deliver a course. The first week is consumed with organizing teams and getting students familiar with the lab environment and the last week is reserved for final exams, during which we perform our project postmortems. This leaves nine actual working weeks for project activities. TABLE I Week 1 2 3 4 5 6 7 8 9 10 11

SE361 P ROJECT SCHEDULE Lab Activity Lab Familiarization – Organize Teams Project Planning - Define User Stories High Level Design R1 User Stories Implementation Release 1 / Reflection R2 Planning R2 User Stories Implementation Release 2 / Reflection Final User Stories Implementation Final Customer Demonstration Postmortem

Requirements & Planning Teams began the planning process by using the customer’s statement of needs and interaction with the lab instructor to write user stories. In XP, user stories are the requirements of the system as specified by the customer in the form of short usage scenarios [4]. A similar concept is utilized in Scrum with the creation of a product backlog list, which defines product features and functionality [9]. A sample user story in our application is: “A single bowler arrives at the bowling alley control desk and is assigned to an open lane by the control desk operator” User stories represent both a description of what the system needs to do and the identification of a parcel of work that needs to be completed by the development team. Due to time constraints and student inexperience we gave the teams a head start by providing a more detailed statement of needs from the customer than one might receive in actual practice. Lab instructors served as surrogate customers to help with the writing of the user stories and an online course


Session S2C discussion area was established to field additional student questions. The development of user stories typically includes an estimate of the effort required to complete the tasks associated with implementing that story [4]. As students developed user stories for the project we had them categorize each task as being of high, medium or low complexity based on their confidence in completing the task. For example a task that would require expertise in an area they were not familiar with - inadequate domain knowledge, building a graphical interface or networking, would be assigned a higher level of relative complexity. At this point we chose not to have teams make actual time estimates in term of hours or days, but had them identify the tasks that could be completed for each release cycle based on their risk assessment and customer priority. Students would then track the actual time spent on the tasks implemented during the first release cycle and use that experience to provide estimates for subsequent cycles. Teams maintained their task list in a simple spreadsheet format that included: • • • • • • •

Task identifier Estimated development complexity Customer priority Estimated time Actual time (tracked) Responsible team member(s) Description of the story to be implemented

This lightweight document served as the central location for the team’s planning and tracking activities throughout the project. The collection of user story descriptions acted as the repository for the system’s requirements. Acting as the surrogate customer, instructors helped teams to establish the customer priority for the order in which features would be released. We established a conservative expectation for the first release to allow teams an opportunity to get up and running. Teams would often over estimate the amount of features they could provide for a release by not accounting for all the development activities required to complete a user story. We also provided some flexibility in what constituted a complete system delivery. Beck presents a model of software development from the perspective of a system of four control variables: cost, time, quality and scope [4]. The customer selects three of the control variables and the development teams controls the fourth. In our project we had a fixed cost (number of students per team), a hard delivery date (end of the term) and high quality expectations. The project’s statement of needs was structured such that it would be improbable that all features could be implemented by the end of the term. While planning releases teams were encouraged to identify features of lower customer priority that could be deferred to the final release, or potentially not be completed at all by the end of the term. This was a

difficult, but valuable learning experience for students who had not had the opportunity in previous classes to significantly influence or negotiate course deliverables. Acceptance Testing After teams had completed the first pass of release planning based on their user stories, they started writing acceptance tests for the initial system release. Acceptance tests for a user story are written along with the definition of the story and are used to capture additional details of the feature to be implemented [14]. This approach forces teams to think about testing early in the development cycle and allows the test plan to grow incrementally along with implementation thus avoiding the end of the project testing crunch. Acceptance tests are used at the completion of each release cycle to demonstrate an agreed upon level of functionality for that release. Tools & Collaboration We found it valuable to structure the team’s activities with the use of an integrated development environment (IDE) that supported configuration management tools and helped to foster collaboration between team members. An additional benefit was that our students would be exposed to the type of development culture more typically found in industry. Our teams used Eclipse3 , an open source IDE written mostly in Java with a well-designed interface to the open source configuration management tool cvs4 . Eclipse is designed primarily for a Java development environment, but has an architecture that supports “plug-ins” to potentially extend the functionality of the tool to other languages. Teams established a simple project structure using Eclipse to house their project task spreadsheet, product design documentation, test plan and directories where their product and test code would eventually reside. Although students had experience working with source control management in earlier courses (Unix rcs 5 ), they did so on an individual basis. The agile practices of collective code ownership and continuous integration required a new level of collaboration that many students were initially uncomfortable with. Eclipse and cvs support the concept of a continuous development stream, with team members updating and committing work products to a common cvs repository. Students skeptical of this approach looked for ways to “lock” files checked out from cvs that they perceived as “belonging” to them. An interesting and repeated phenomenon was observed as teams determined the division of labor for the project’s components. Although encouraged to physically work together as a team during their out of lab working sessions, each team member, or a group of members, took responsibility for a component of the system and then 3

http://www.eclipse.org http://www.cvshome.org 5 http://www.gnu.org/software/rcs/rcs.html 4


Session S2C proceeded to work on their artifact in relative isolation from the rest of the team. Some time later the team would come together for an integration session only to find difficulty in piecing together the now disparate parts of the system. These same teams ultimately changed their approach to integration and developed the remaining releases in a more collaborative environment Several teams readily admitted during the course postmortem that they wished they had initially spent more of their individual development time working together in the same physical location to improve communication within the team and minimize the rework typically performed during their integration sessions. Evolutionary Design Each release cycle consisted of teams implementing a selected set of user stories based on customer priority. Implementation would consist of performing the life cycle activities (design, code, test) required to deliver the functionality specified by the user stories along with the corresponding acceptance tests to validate those features. Teams proposed what features would be delivered in each release with the input of customer priority, which was provided by the lab instructors. For the initial cycle we started teams with a layered architecture to reinforce the value of separating presentation concerns from the responsibilities of the domain or model component of the system. The features we identified for the first release were encompassed within the domain component and had teams focus on an initial design that would support the implementation of those features. Teams were instructed to consider a design that only addressed the needs of the current release cycle and was “the simplest thing that could possibly work” [4]. Many teams found difficulty with this constraint and looked ahead to potential design issues not related to the current set of functionality and based on the assumption of introducing new requirements. One team for example insisted on a JavaRMI design to accommodate a distributed architecture even though there were no networking or distribution requirements stated by the customer. As teams worked through each of the release cycles they had the opportunity to evolve their design staring with a skeleton of the classes needed for the initial release and gradually fleshing out the details and adding or removing classes as additional features were implemented. Designs were developed and documented using standard UML notation and tools – class diagrams, sequence diagrams and state charts. Students were also introduced to the elementary design patterns that were appropriate for their projects. The weight of design documentation, amount of UML, and use of design patterns is often debated between the traditional and agile communities [8]. We took an approach proposed by Fowler [17] that UML techniques are useful as a tool for exploring a design prior to implementation and as a vehicle for communicating a design

to others. UML design documents were required to be in synch with the team’s implementation at each release cycle. Unit Testing As part of the design process students were introduced to the concept of test-driven development (TDD) [7]. TDD contributes to the process of evolving a design by requiring the developer to devise a test that causes the current implementation to fail, then designing and implementing the code that will satisfy the conditions of the failing test. Development proceeds in quick, small increments until an entire suite of tests has been established. As each new test is conquered a regression test is run to verify all previous tests still pass. A feature is deemed complete when all tests pass. The default installation of the Eclipse IDE includes a plug-in for the JUnit 6 test environment. JUnit provides a framework for creating and maintaining unit tests. It also allows the developer to quickly run regressions tests at any point. Given their inexperience with design in general, students were understandably slow to embrace test-driven development in its purest form, but eventually warmed to the use of the JUnit framework for unit testing code developed in the traditional approach. The JUnit approach to testing is known to have an infectious quality that many of our students were attracted to after a few rounds of writing and (successfully) executing unit tests they had devised. Raising the consciousness of students with respect to unit testing was one of the more rewarding outcomes of the project’s format. Reflection At the end of each release cycle and ultimately at the end of the project we had teams engage in a reflection or postmortem session with their lab instructor to identify opportunities for process improvement. Teams would reflect not only on process shortcomings, but also on activities that worked well and then determine how to capitalize on those successes. There was a modest collection of measurements that we asked students to record to be used towards creating process metrics. Team members were required to track the number of hours spent on the development of each user story and the number of defects found during reviews, code inspections and testing at each level. During the project postmortem teams combined these measurements with the number of classes and lines of code to create fundamental project metrics - LOC/hour, defects/LOC, etc. Students were also required to submit confidential peer evaluations related to the performance of their team and individual team members. Collecting this information in the first reflection session also allowed instructors the opportunity for early intervention in the case of dysfunctional teams.

6

http://www.junit.org


Session S2C CONCLUSIONS We found the use of agile software development techniques effective in an introductory software engineering course project. The areas where agile development techniques were of most benefit: •

•

•

•

Developing user stories provided students with an introduction to project planning and documenting customer requirements. The planning exercises also had students think about issues related to customer priorities and managing development risks. Delivering increments of the system throughout the term provided teams with opportunities to reflect on the release just completed and apply process improvement initiatives to subsequent release cycles. Teams were also presented with the opportunity to refactor design and code as required in manageable increments. Continuous integration supported by the use of an integrated development environment introduced students to working collaboratively as a development team. Students were introduced to procedures for the effective use of tools that supported product integration, testing and configuration management. An awareness of testing throughout the entire development process was perhaps the most valuable experience for our student teams. Starting with the creation of acceptance tests in parallel with the development of user stories and continuing on with the emphasis on unit testing, students no longer viewed testing as exclusively being an end of the project activity.

Potential areas for improvement in SE361 would include a formal incorporation of pair programming. Many students did gravitate towards working as pairs, but in an adhoc manner. We ran into the same challenges of previous classroom based pair programming activities – students were only under the instructor’s guidance for the duration of the lab period and then were then on their own to coordinate out of class scheduling [15]. Introductory programming courses using pairs have had more success due to assignments that better fit the scope and time frame of a single lab session [16]. While most of the work with agile development methods has been applied to our introductory course, we have also found it suitable for our upper division courses and senior capstone projects as well.

[2]

Lutz, M. “Using Patterns to Teach Software Subsystem Design”, 29 th ASEE/IEEE Frontiers in Education Conference, San Juan, Puerto Rico, November 10-13, 1999

[3]

Williams, L. & Upchurch R. "Extreme Programming For Software Engineering Education?", 31 st ASEE/IEEE Frontiers in Education Conference, Reno, NV, October 10-13, 2001.

[4]

Beck, K. Extreme Programming Explained: Embrace Change. Boston, Massachusetts: Addison-Wesley, 2000.

[5]

Hislop, G., Lutz, M., Naveda, J., McCracken W., Mead, N. & Williams, L. “Integrating Agile Practices into Software Engineering Courses”, Computer Science Education, Vol. 12, No. 3, pp. 169-185

[6]

Shukla, A. & Williams, L. “Adapting Extreme Programming For A Core Software Engineering Course”, 15 th Conference on Software Engineering Education & Training, Covington, Kentucky, February 25-27, 2002.

[7]

Beck, K. Test-Driven Development By Example. Boston, Massachusetts: Addison-Wesley, 2003.

[8]

Boehm B., Port, D. & Brown, A. “Balancing Plan-Driven and Agile Methods in Software Engineering Project Courses”, Computer Science Education, Vol. 12, No. 3, pp. 187-195.

[9]

Schwaber, K. & Beedle, M., Agile Software Development with Scrum . Upper Saddle River, New Jersey, Prentice Hall, 2002.

[10] Lethbridge, T. “What Knowledge is Important to a Software Professional?”, Computer, Vol. 33, No. 5, May 2000, pp. 44-50 [11] Johnson, D. & Caristi, J. “Using Extreme Programming in the Software Design Course”, Computer Science Education, Vol. 12, No. 3, pp. 223-234 [12] Abrahamsson, P., Salo, O., Ronkainen, J. & Warsta J. Agile Software Development Methods. Review and Analysis. Espoo 2000, VTT Publications 478 [13] Shepard, T., Lamb, M. & Kelly, D. “More Testing Should Be Taught”, Communications of the ACM, June 2001, Vol. 44, No. 6, pp. 103-108 [14] Martin, R. Agile Software Development – Principles, Patterns and Practices. Upper Saddle River, New Jersey: Prentice Hall, 2003. [15] Umphress, D., Hendrix, T. & Cross, J. “Software Process in the Classroom: The Capstone Project Experience”, IEEE Software, September/October 2002, pp. 78-85 [16] Williams, L. & Kessler R. Pair Programming Illuminated. Boston, Massachusetts, Addison-Wesley 2003 [17] Fowler, M. “Is Design Dead?”, Extreme Programming Examined, Succi, G, & Marchesi, M.,eds., Reading, Massachusetts, Addison Wesley, 2001.

REFERENCES [1]

Naveda, J. “Teaching Architectural Design in an Undergraduate Software Engineering Curriculum”, 29 th ASEE/IEEE Frontiers in Education Conference, San Juan, Puerto Rico, November 10-13, 1999
