CeAL Case Studies in Active Learning

1. A case study of Research Led Learning in Computer Science: software project management in which final year students’ manage teams of second years

2. Contact Information:

Liz Burd
Computer Science
Durham University
Phone: 0191 334 1719
Fax: 0191 334 1701
Liz.Burd@dur.ac.uk

3. Context

Module — Project Management (linked to Software Engineering)
Level 3

4. Brief Description

In Durham students have an opportunity to take a module within their third year in Project Management. The ideal learning experience for this module would be to include a work placement to enable students to gain experience of the realities of managing a team. For a variety of reasons this is neither possible nor practicable and therefore we sought to identify other opportunities for students to gain a similar experience of managing software projects. This case study details how we enable our students to have experiences similar to those they would have gained from work placements. Furthermore, we then show this in the context of how we engage our students within a research project where they are the direct providers of the research outcomes.

5. Course Description

To gain experience of project management our third year students are asked to manage teams of second year students participating in a module on Software Engineering. This work forms part of the core Software Engineering module’s assessment where students participate in a software development team working exercise. This Software Engineering module itself involves a number of innovative learning experiences and therefore significantly contributes to the rich learning environment experienced by those students studying project management. The group working approach of the Software Engineering module is now described.

The second year software development group working exercise requires students to work in teams for an academic year to design and develop a software system. In academic year 2007/8 this software development work is defined by an industrial partner to the project, Proctor and Gamble. Working in collaboration with the academic staff the industrial partners set the problem and manages the requirement definition process. Students negotiate directly with appointed members of the company in terms of proposals for system design and definition of any fuzzy parts of the initial specification.

What is also innovative about this particular team working module is the way students are grouped. Students are grouped into companies, where a company comprises of a group of students from Durham University and a further group from Newcastle University. Therefore, similar to the situation in many companies software development companies, teams are dispersed and therefore communications channels are largely not face to face, but through technology such as video conferencing. Student companies are required to produce a single software application between them as well as agreeing all other deliverables. Therefore communication between the sites must be high if the project is going to succeed.

From the brief outline of the group work it is clear that the management of this work is a challenging task and in many cases the process mirrors the complexities of industrial software development. The project managers are asked to manage the teams in Durham, but they do not manage the Newcastle teams so they only have partial management responsibility of the work and have to negotiate with the Newcastle group should any problems occur. This is again similar to the lines of responsibility any manager of a cross site development would encounter.

The research led aspect of this work comes from a collaboration between Computer Science and the Business School within Durham. Part of the research collaboration between these Schools involves a research project to investigate the use of patterns within management (Coplien and Harrison, 2005]. Like design patterns business patterns are proposed to assist a manager to solve problems. In the case of business patterns they are intended to represent business decisions relating to problems that a project manager may encounter. We see our project managers and partners within this research project.

As part of their assessment the project managers in Durham are asked to produce a reflective log (using a wiki) of the problems that they encountered while managing their group and the solutions that they used to resolve these problems. Thus students contribute to this research collaboration by documenting their problems / solutions in the form of patterns. Our experiences have shown that often students are better at producing patterns that more experienced project managers. We hypothesis this is because students are still leaning how to solve management problems and therefore are less prone to make assumptions when documenting patterns than the more experienced managers. Each pattern has an author so that students submitting a pattern have a sense of accomplishment that they provide new knowledge to the research community and also support later cohorts of students as all patterns (with permission of the student) are made available for later cohorts of students to use.

The outcome of this work has lead to the creation of over 50 new patterns and considerable reflection on existing ones. The analytical nature of the review process encourages students to employ high level skills such as evaluation and analysis. What is more the creation of patters and their submission to the community provides students which a strong sense of achievement that is rarely achieved with more traditional university assessments.

6. Tips

You need to match numbers of students with the numbers of groups. We now use 2 managers per level 2 group. This is helpful in case one of the managers is ill etc. The module is popular so this is not a problem. We have run these modules with varying numbers of students. Total registrations have no impact on the approach, but what does matter is the proportion of project managers to groups. For the group work we have found that groups of 5 or 6 are optimal so ideally therefore should be a 1 to 3 ratio project managers to level 2 students.

7. Does it work?

Students provide very positive response to this module, especially with relation to the feedback that they get from employers when attending interviews.

8. Problems that have arisen

Some time too many students have registered (i.e. we fail to obtain a 1:3 ratio), but on occasions where greater proportions of level 3 project management students have registered we defined roles more as personal mentors rather than managers. This was less satisfactory, module caps may be a better solution.

9. Assessment

The module is 100% course work. Students focus on patterns for each assignment. The three assessments are:

• A presentation (20%)
• The pattern wiki (30%)
• A reflective overview of the use and creation of patterns to assist management (50%)

10. Further information

http://eprints.ecs.soton.ac.uk/14913/
Coplien J.O., and Harrison N.B. (2005) Organisational Patterns of Agile Software Development Prenti

29/05/2008

For more information on the Centre for Active Learning contact:
Barbara Rainbow, CeAL Administrator, Tel: +44 (0)1242 714683, E-mail: brainbow@glos.ac.uk
Sonia Chilton, CeAL Administrative Assistant, Tel: +44 (0)1242 714615, E-mail: slchilton@glos.ac.uk