In a constantly changing business environment, whether an Information Technology (IT) solution meets the users' requirements is no longer dependent on whether the delivered product conforms to its plan, but whether it satisfies the customers at the time of its delivery (Erickson, Lyytinen & Siau, 2005). The module, CS3214 "Information Systems Development Project", which I teach at the Department of Information Systems in both Academic Years 2006/2007 and 2007/2008, emphasises the principles of agility, flexibility and adaptability, and prepares third-year computing undergraduates for increasingly dynamic business environments.

CS3214 is a 100% continual assessment projectbased course in which students are offered an opportunity to learn about multi-tiered software development architecture. We use the Critical Adoption Factors for Agile Methodology developed by McAvoy and Sammon (2005) to design our course along the project, team and customer dimensions. A project specification is released to student teams in week 1 of the semester and is deliberately designed to be ambiguous (i.e. the requirements are subject to frequent changes). Each team of five to six students is then instructed to develop an enterprise-level system using Java Platform, Enterprise Edition (Java EE), and assigned a project advisor who also acts as the user. This allows the user to be onsite and be an integral part of the team.

The following points summarise the key characteristics of CS3214:

Course Workload

CS3214 emphasises team-based guidance rather than lecture-based teaching. In this regard, the time demanded from both the lecturer and tutors will be significantly higher than other courses. For students, developing a system within a 13-week time frame can be a very demanding task. As a reward, students taking the course earn eight rather than the usual four module credits.

Preparatory Workshop

A preparatory workshop focusing on Java EE programming is conducted two weeks prior to the start of the semester with an objective to equip students with the necessary knowledge and skills in programming, enterprise-level system architecture and software development methodology.

Choice of Project Team Members

Students are allowed to choose their own team members and are accountable for whom they have chosen to work with. The preparatory workshop also offers an early opportunity for potential team members to socialise and understand each other's strengths, weaknesses and working styles through hands-on exercises.

Project Specification

Two factors are taken into consideration when draf ting the project specif ication. Fi rst, the selection of the business/problem domain is less dependent on the lecturer's preference but more on the composite aggregation of students' preferences, choices of the industry players, trends in the IT market, course objectives and the scope of evaluation. Second, selected industry players are invited to read and comment on the project's specification for realism.

Requirement Analysis

Students begin the planning process in week 1 by formulating usage scenarios. Advisors acting as surrogate users help teams visualise the system as a whole and plan the release schedule. Teams are also encouraged to identify functions of lower priority that can be deferred or even excluded from the final system. The output from the requirement analysis is a list containing the functional requirements, the dependencies among the functions, the complexity of each function categorised from low to high, the estimated amount of effort needed and the priorities associated with the functions. The schedule also serves as a monitoring device for teams to plan and track their activities.

Additional Requirements

Advisors often introduce one or more additional requirements (i.e. 'shocks') to train students to be adaptive to changes. Based on consensus between advisors of selected teams and other neut ral advisors, only the top 10% of all the teams (about 3 or 4 teams) are given the 'shock' treatment. Weaker teams which are already experiencing difficulties coping with the initial set of requirements are often excluded. To compensate for subjectivity in the identification of stronger teams, 'shocks' are not explicitly stated but discreetly delivered during the consultation sessions between the advisors and their respective teams.

System Releases

Students are constantly reminded that the bulk of the assessment rests on their ability to deliver a working, integrated system. While we do impose continuous assessment throughout the semester, the evaluation of the system at its final release constitutes the bulk of the final grade. This is consistent with industry practice where the client pays the software vendor only when the system has been delivered. At the end of each system release, teams will engage in debrief sessions (i.e. post-mortems) where evaluators identify not only software flaws but also other areas for improvement. The final evaluation of the system is conducted in a way that simulates a real-world business situation where teams present and demonstrate their systems to the clients.

I hope this article, which documents my efforts in improving the quality of CS3214 over the last two years, would invite discussion and draw attention to the importance of aligning our teaching methods to research developments and industry practices.

Acknowledgements

The author gratefully acknowledges the assistance of Associate Professor Teo Hock Hai as well as Mr Tan Wee Kek and Ms Tong Yu (teaching assistants) in the planning and implementation of the curriculum.

References

Erickson, J.; Lyytinen, K. & Siau, K. (2005). "Agile Modeling, Agile Software Development, and Extreme Programming." Journal of Database Management, Vol. 16, No. 4, pp. 88-100.

McAvoy, J. & Sammon, D. (2005) "Agile Methodology Adoption Decisions: An Innovative Approach to Teaching and Learning," Journal of Information Systems Education Vol. 16, No. 4, pp. 409-419.