Some Experiences in Teaching Teamwork Programming Janusz Jablonowski

Transcription

1 Some Experiences in Teaching Teamwork Programming Janusz Jablonowski Abstract: The paper describes experiences gained during last six years of teaching teamwork programming at the Warsaw University. We describe the background, history and evolution of this study subject. We summarize our discussion with some remarks about the importance of such subjects in software engineering study and possible future enhancements. Key words: Programming in general, software engineering, computer science education, teamwork programming. INTRODUCTION In this paper we summarize our experiences gained through last six years in teaching teamwork programming at the Institute of Informatics of the Warsaw University. The rapid development of the demands towards software engineering and the fast broadening of the area of computer usage in our everyday life has resulted not only in a large number of programs written every month, but also in significant complexity of these programs. A typical application nowadays must have: nice, easy to use, graphical user interface, advanced, contextual help system, often with various kinds of wizards for typical tasks, ability to work in a network environment, and most of them are even network based, some kinds of data protection, ranging from simple account systems with various rights levels, to sophisticated ciphering systems, etc. All these tasks require a lot of analysis, design and programming (e.g. creating a GUI which well suits user needs and is easy and intuitive in use requires very careful design). The result of all these requirements is such that it is impossible nowadays for one person to deliver an application to a client in a reasonably time (if at all possible). (Of course the need for teamwork on programs did not emerge recently, large programs were written almost from the beginning of computer era, but nowadays the importance of cooperative work is most obvious.) The various tasks to be done during software development have resulted in obvious division of involved persons into analysts, designers and programmers. Surely a project should also have its supervisor. Often there are even more roles in a team (for example, with large programs, there are separate groups of people dealing with software maintenance or with customers support, teaching, etc.). But it is not only the need for fulfilling different task that makes teamwork necessary. Each of the above mentioned tasks (with the exception for supervisor), usually requires much more work, than one person is able to do. So there is not only need to cooperate with people assigned to other tasks but also to work together with people assigned to the same task. From the above discussion it is clear, that the ability to work in a team is crucial for programmers (and analysts and designers too). In fact the teamwork is essential in many other human activities, but it is out of the scope of this paper. So the question emerges, how to teach teamwork programming during the software engineering study. That question is not easy to answer. First problem is connected to the nature of the subject: it is a practical and not theoretical one. And that makes teaching much more difficult. When teaching a subject with good theoretical background there is only a problem of selecting a proper set of definitions and theorems which will cover a reasonably wide and important part of the subject. It is then also relatively easy to assess

2 the progress made by the students. In case of teamwork programming it is not possible. There is of course a lot of literature about this subject, but there is no theory in them. They describe experiences of the authors and give clues, in form of heuristics, how to organise the work of a team. So the conclusion here is that the best way to teach teamwork programming is not only through lectures (although some background is of course necessary) but through some kind of case studies and exercises. The second problem is as follows: the difficulties of teamwork are best visible when the team and the project undertaken are large. This of course does not fit well with the structure of academic teaching. It is practically impossible to organize anything what will take longer than a year. This is due for example to the fact that the set of students usually changes from one year to another. It is also hardly possible to organise more than one meeting a week for students and of course real work on a large task requires much more frequent cooperation. In the next parts of this paper we will describe the solution to this problem established at our institute. BACKGROUND The teaching of teamwork programming at our institute has long tradition. Almost from the beginning of software engineering studies there were introduced laboratories in this subject. There were of course many changes in the structure of this subject, but it was dealt with for all the time. In this paper we will describe the last period ranging from It is not because the earlier attempts to teamwork programming were less important, but because in 1997 starts the period when the author of this paper has been designing the curriculum for this subject and was coordinating these activities. In early 90-ties there was a reorganization of our curriculum. One of the aims of the reorganization was to set all subjects to last for one semester only. This was in contrast with previous curriculum, where some subjects lasted for one semester and some for one year. One of the results of this reorganization was the disappearance of the one year laboratory where students were developing their programs in small teams. In 1996 the author of his paper was assigned a task of preparing a new one semester subject devoted primarily to teamwork programming. In contrast with previous approaches at our institute this time teamwork was set to be the only aim of the subject. Earlier the laboratories at which students were working in teams were also devoted to other tasks as teaching new languages (e.g. Modula 2). The change was also reflected in the name: Teamwork Programming Project. One of the assumptions was to base the project on object-oriented methodology. This choice was quite natural the object oriented methodology is dominating now, and its virtues are especially evident in the case of large software systems. According to our previous experience this subject was planned for the second study year, for fourth semester. It is obvious that first year of study is too early for such a subject. The fourth semester was chosen, because at the third semester our students take a course in object-oriented programming, hence combining these two subjects during one year of study seemed perfectly reasonable. There were already many laboratories at the third year, so this one was not considered appropriate. Years fourth and fifth are after the bachelor level, so putting teamwork programming only there would mean that not all of our students will go through it. And this is not desirable because of the nature of this subject and of our study. Those students who leave our study after the third year (bachelor) are those who want to go into industry as soon as possible and do not feel much interest in the more theoretical aspects of computer science. Our curriculum is organised so, that the last two years (of five years long master of science study) are devoted to specialized studies connected to the master thesis. We also teach some more advanced topics here, often connected to the theory of computer science. Hence if we would assign teamwork

3 programming to one of these two years, then those students who actually need this subject the most, would missed it. GOALS AND ASSUMPTIONS When starting the design of a new (well, in this case not brand new) subject, one has first to identify the goals which are to be fulfilled by the subject, then the assumptions which have to be made about the knowledge of students taking this subject. Here is a list of the most important goals I have formulated then: Make students aware of the importance of teamwork As it was stated in the introductory part of this paper, teamwork programming is extremely important nowadays for anybody wanting to work in software engineering. But this is not the knowledge students have or gain during the first year of study. Quite the contrary the first year laboratories are dedicated to programming in the small, that is students write small programs which should make them familiar with the chosen programming language, with data structures and with algorithms. There is no need or possibility there to show the benefits of teamwork, students at this time just have too small knowledge. Also the problems they are given are too easy to be worth solving in a team. So we have somehow to convince our students that they need something more than just working alone. It is not easy to do; perhaps the best method is just to assign a reasonably large task to be done. We prepare student to these work with some kind of advertising of teamwork programming we explain why it is so important during first meeting before the subject actually starts, we put some arguments in the subject description on the net (all subjects has such descriptions available to our students through Internet). Make students aware of the problems of teamwork At least as important as the previous goal is to show to the students that teamwork although necessary is not easy. After writing by themselves a number of programs the students know about difficulties with the environment which is not always as user friendly as it is advertised, with the compiler which not always gives clear explanations of errors and warnings, with the language which may have some pitfalls and with the algorithms which are often difficult and sometimes hard to implement. But they do not comprehend what are the difficulties in cooperative work. At the first meeting we emphasize, that writing a program by one person in twelve months does not mean, that twelve persons will write it in one month. We highlight the problems with communication between team members. We stress the need for common conventions in describing designs and coding. From the start we try to make students aware of human problems, that for example it is better to be in one team with reliable colleagues than with more than one outstanding student. Unfortunately this part of lessons students should gain from this subject is the most painful one those who really learn it are those who were not lucky enough to be in a good cooperating team. But nevertheless we are sure that is it still better to learn this lesson at the university than later, during regular work. Show students tools for teamwork When students know that teamwork is necessary and difficult it is the best time to show them tools which will make their work easier. There is a lot of them, but we are concentrating on same representative choice. First of all we show CVS [1], a tool which makes it possible to manage the changes in their projects. It is just the time when the possibility of retrieving old versions of modules is so important, just to see if the fault in the work of the entire project is due to last changes in my or my colleagues modules. Of course we show some up to date environments for programming (these depend on the

4 chosen language, eg. Sun ONE [2] for Java). We put much stress on documentation, so we have to show same tools easing the hard work with documenting programs (eg. JavaDoc [3] in case of Java). The next important task with large projects is their maintenance we show tools which enable keeping track of submitted bugs, of the current status of the bug, of who is responsible for fixing it etc. (eg. Bugzilla [4]). Show students as much as it is possible the entire lifecycle of a project This is of course most difficult to organise during study. For example the extremely important part of a project lifecycle starts after the project is released to customers and they submit their notes, ides and criticism about the system. Most of this feedback should be taken into account, either as corrections to the current version or in the next version of the application. It is obvious that there is no possibility to provide to our students enough customers and time for maintenance. Nevertheless we try very hard to make this exercise as close to real life as possible. First of all, we do not start with the precise requirement specification it is the task of the students to write it down. We only give rough description of the needed application, and then we are ready to answer students questions (personally or by ). So the students are responsible for finding what exactly is needed. The requirement specification is then evaluated by the person supervising the project, and some corrections are if necessary introduced. We demand the full design and project documentation after each step of design the documentation is evaluated by the students supervisor. And at the end, when students give us the final version of the project, we evaluate it and after that we ask for some change in the project. Of course students know from the beginning, that something like that will happen, and we tell them which kind of modification it may be. These are small modifications, which with a proper design of the system require not more than one day to be done. The aim of this is to make students sensitive to the need (or rather necessity) of modifying programs. Teach students how to present own work or what they have learned Of course it is again something what cannot be taught other way than just by exercising. On the other hand it is extremely important. Presenting own work is something what students (not only of software engineering) will have to do during all they professional life. Presenting what they have learned is import in teamwork: when a team has to learn new technology it is desirable that some members of the team will study it and then present it to the others. So I have included in the curriculum of this subject presentations. These are presentations of the tools that students have to use during the development of the project. I personally consider them an important part of the subject. Assumptions These were quite obvious, due to the incorporation of the subject into our curriculum. The students must be fluent in programming in the small. They should have good knowledge of object oriented programming. Organization One of the most difficult decisions was how many students should be in one team. If the number is higher then the project will be more realistic. But on the other hand it will be more dangerous for the students they have no (or little) experience in working in a team, so we should not put them into too deep water. After long consideration we accepted numbers 3 to 4. At the beginning it was 3, and then it changed to 4. All students are divided into laboratory groups. Each laboratory group has its supervisor a teacher from our institute. Each group consists of 3-5 teams. Usually all teams have the same task. The presentations are made for the entire group.

5 Supervisor (teacher) Group no 1 Group no 2 Group no 3 Figure 1: A strucure of one laboratory group SHORT HISTORY Here we give short history of teaching Teamwork Programming Project (TPP): 1997/1998 First year of teaching TPP. There were different programming tasks in different groups. An example problem from one group: write a structural editor parameterized by the syntax and formatting rules of a programming language. 1998/1999 Second year of TPP. This time all groups were assigned the same tasks: to write a visual game with rich GUI and sophisticated hierarchy of objects. 1999/2000 Third year of TPP and last before important changes. The tasks we assigned to students was this time extremely practical to write a subsystem of the faculty management system. The subsystem s task was to register students for laboratory and exercise groups. 2000/2001 This year there was no TPP due to changes in structure of our curriculum. As a result TPP was moved to the third year of study, with the benefit, that it is now after Software Engineering. Also TPP has changed now it lasts for entire academic year, but the meetings are once a two week period. Also final presentations of all teams for everybody interested from faculty were introduced. Due to the fact that there is now more time, we have raised the number of students in one team to /2002 First year of the new TPP. All groups have different tasks. An example task from one group: write a system for supporting the development of provably correct programs. 2002/2003 In progress now.

6 CONCLUSIONS AND FUTURE WORK There is no question whether we should teach teamwork programming. It is obvious that we should, some arguments for this were given in the introductory part of this paper. But there is an open question how to do that. We have shown in this paper some problems connected to teaching this subject. We have also shown how we try to solve these problems at the Institute of Informatics of the Warsaw University. We do not claim that these solutions are perfect, on the contrary, as can be seen from the shown history they are still evolving. But these solutions at present are the best we could think of. We are sure they will help our students to successfully work in the future. REFERENCES [1] [2] wwws.sun.com/software/sunone. [3] [4] ABOUT THE AUTHOR Lecturer. Janusz Jablonowski, PhD, Institute of Informatics, Department of Mathematics, Informatics and Mechanics, University of Warsaw. Phone: (+48 22) ,? -mail: