Design Based Learning in the Curriculum of Computing Science a Skilful Struggle Authors: Jacob Perrenet, Technische Universiteit Eindhoven, Educational Service Centre, Eindhoven, The Netherlands,
[email protected] Ad Aerts, Technische Universiteit Eindhoven, Department of Computing Science, Eindhoven, The Netherlands,
[email protected] Jaap van der Woude, Technische Universiteit Eindhoven, Department of Computing Science, Eindhoven, The Netherlands,
[email protected]
Abstract A new learning environment, called Design-Based Learning (DBL), was incorporated in a Computing Science curriculum, as part of a university-wide process. The aim was to design and implement a series of group projects for the first and second year. The question which design elements could play a role in an early phase of the curriculum was to be examined, and the previously independently offered skills training courses were to be embedded more coherently. In this paper the central topic is the position of skills training in the curriculum. DBL provided the opportunity to practise discipline-related design skills as well as more general skills such as project skills, group skills and communication skills. We will focus upon the general skills. Looking back at the developments in our skills training program, we identify three different stages: isolation, integration and selection. It proved to be important to integrate skills in such a way that students perceive them as useful and to identify core skills. We conclude that in a Computing Science program, the core skill is reporting. Also, skills can have various roles: they can be an end or a means or even both and sometimes this role can change. Finally, we point out that the process of curriculum development has some partly irrational aspects too. Index Terms skills, computing science, design based learning, project work. INTRODUCTION There are three technical universities in the Netherlands; the Technische Universiteit Eindhoven is one of them. For some time employers had been complaining about the level of graduates’ skills. In general they were satisfied with the thorough subject knowledge of TU/e engineers, but they also stressed that this knowledge had to go hand in hand with the ability to critically apply it in an industrial setting and in multidisciplinary teams of designers. Therefore, in its Institutional Plan for 1998-2001, the TU/e announced that it would develop a university-wide educational philosophy for the university-based training of engineers: Design-Based Learning (DBL) [1]. Since design is the central activity in engineering, the design process, including its features such as professionalization, activation, co-operation, creativity, integration and multidisciplinarity, should be important in engineering education. The educational innovation DBL implied that all nine Faculties committed themselves to introducing these features into their programs or to strengthening them. These programs vary from Applied Mathematics to Technology and Society, from Biomedical Engineering to Architecture. There are thirteen programs with a total of approximately 6,500 students. Fundamental motives underlying the introduction of DBL were: to improve the quality of education, to increase students’ levels of competence, to reinforce the coherence between education and research and to strengthen cohesion between the Faculties [1]. For each of the existing programs, its Faculty outlined a DBL-plan. In some cases this comprised the intensification of an existing activity, in other cases it involved new activities. Another, global, plan was to work towards multidisciplinary inter-faculty projects, with students from several Faculties working together. Educational support was provided by the Educational Service Centre of the university for a period of two years. In this paper we will analyze the implementation process and the experiences with DBL in the program of Computing Science. (See [2] and [3] for reports of the overall implementation process at the TU/e). We will sketch the substance of the program at the outset of DBL and the way in which the program was restructured. Our focus will be on the role of general skills in the first two years of the program. We will describe the various skills and discuss their importance for Computing Science both from a discipline-related and from an educational viewpoint.
International Conference on Engineering Education
July 21-25, 2003, Valencia, Spain 1
Looking back, we observe several stages in the development of our skills training program. A first stage with limited and isolated skills training at the outset of DBL was followed by a second stage with an increasing variety of skills training, immersed in projects. Finally the realization dawned that this large training program took too much time and that integration with the project work was not always successful. So the decision was made to diminish some, postpone others and choose a focus. The focus became reporting (in Dutch). Besides that we observe the phenomenon of ‘didactical conversion’: the change of role of a skill in a curriculum, for instance from goal to means. In conclusion we will pay attention to the fact that an innovation process also has aspects that are not completely rational.
THE COMPUTING SCIENCE PROGRAM AND THE DBL INNOVATION Since 1996 Computing Science has been a five-years program; since 2002 the Bachelor-Master structure has been incorporated. Subject matter of Computing Science Computing Science describes and designs information processing systems and develops theories, methods and techniques for the construction of such systems. Typical for the classic Eindhoven school of thought is the thoroughly mathematical character of the program; the focus is upon correctness by construction, reliability, and the use of formal methods for design tools. The modern development in software engineering, which starts with system component construction before bringing the components together, has recently been incorporated. The basic knowledge of a future bachelor should consist of knowledge of the following domains: mathematics, computing science theory, programming, computer architecture and system programming, information systems, technical applications, decision theory and stochastics, and technology management. On the other hand, the bachelor should also have professional skills in various categories: group skills, communication skills, project skills and design skills. Group skills are the most general and design skills are the most specific, but in every skill there is a mix of general and discipline-related aspects. In Table I the skills are set out in more detail. Problems with skills Years before the DBL innovation, educators started to realize that for the academical and professional education of the computing-science engineer, more is needed than just a set of subject courses. Alumni and an external advisory council made it clear that the newly graduated engineers were inexperienced in teamwork and were generally lacking in verbal as well as in written communication skills to express their professionally often well-formed ideas. As a consequence, firstly the course Communication Skills was incorporated into the curriculum. Secondly, three existing unrelated small projects were transformed into the large Software Engineering Project in the third year. The former small projects together took 14% of planned study time in a year; the project groups had two to four members. By contrast, the Software Engineering Project takes 21% of planned study time; the project groups have eight members and work for external customers. The structure of the course was inspired by the post-masters program in technological design. Despite the extra attention for communication skills and project activities, the combination of these two courses proved to be less than effective. Communication Skills offered some good introductions to verbal and written communication, but fell short in coaching and feedback. During the Software Engineering Project the students experienced teamwork for the first time. Therefore most of the energy was absorbed by the group process, while little energy was left for the software engineering itself. New opportunities because of the DBL innovation The DBL innovation made it possible to train design skills as well as group skills, communication skills and project skills, in the first and second year. Because of that, the isolated course on communication skills became obsolete. Moreover, the new third year students were expected to be well enough experienced in teamwork to concentrate on the other aspects of developing software in large groups. The plan for the implementation of DBL into the program of Computer Science aimed at an integrated tutorial for the first and second year. The idea was to examine the question which design elements could play a role in an early phase of the program. Moreover, the practical elements of the curriculum originally offered separately were to compose a new, more coherent part in the curriculum. Specific attention should be paid to practicals and to working in teams. Six projects were defined for the first and second year, one project every trimester, to be executed by groups of about six students. DBL should function parallel to other courses, sometimes related, sometimes not, and take 14 percent of yearly study time. The contents
International Conference on Engineering Education
July 21-25, 2003, Valencia, Spain 2
of these projects will be described in Table II. Every project had a theoretical and a practical component; see Table III. In this new structure, the existing Software Engineering Project got a new function: the integration of skills in a larger project. We will not go into more detail concerning the discipline-related skills, but concentrate on the general skills.
DEVELOPMENTS IN THE SKILLS PROGRAM Comparison after two years Table IV shows the development in the training program of general skills. The columns headed Program 2000/2001 give an overview of the plans at the beginning of the first complete implementation (2000-2001). The abbreviations S, T and R signify stimulation, training, and repetition. Stimulation is explanation - orally, digitally or on paper - before practice in the project assignment. Training is explanation and practice with feedback from a professional trainer parallel to practice in the project assignment. Repetition is repeated practice within the project assignment with explicit tutor attention (in general, after training, many skills are required in the consecutive projects, without giving them such didactic attention). The term ‘other’ stands for other courses, for example the Software Engineering Project in the trimesters 3.2 and 3.3 of the third year. The columns headed Program 2002/2003 give an overview of the planned skills program two years after that (2002-2003). Comparing the two skills programs, we will describe and explain the changes. • A smaller variety of skills have been immersed in the DBL-projects. • More skills have been immersed in other courses (especially in the Software Engineering Project). • Reporting in Dutch has been chosen as a core skill; reporting is meant in a broad sense: from giving a presentation to making documents. • Reporting in Dutch being a priority, reporting in English has been placed elsewhere: it is postponed to the third year; in addition, all education in the fourth and fifth year, the Masters years, will be in English. • Typical software engineering project skills, such as progress control and quality management, have been postponed until the SE Project in the third year; in this larger project, these skills have a more natural context. • Also interviewing has been postponed to the third year; again the context is more natural in the SE project, because in that project the students meet an external client for the first time. • A new skill is the skill of peer assessment. Originally peer assessment was introduced to stimulate equal involvement in the group work, that is to decrease free riding. Afterwards it was recognized that assessing peers (and assessing oneself) is in itself an important academic skill. Reporting in Computing Science Documents containing descriptions of (information) systems are central to the discipline of computing science. There are a large variety of such documents. At one end of the range there are those in natural language capturing the requirements for the information system or component to be designed and built, that should be clear to the project sponsor. At the other end are machine-readable documents containing (annotated) code that can be executed. In between there are refinements and reformulations from all kinds of perspectives and for many purposes, mostly technical. Computing science engineers spend a major part of their time composing such documents or transforming one kind of document into another, supplementing the details required in the process and recording the design decisions involved. Moreover, not only is the clarity of the documentation important for the intended readership, also the constructors will benefit from the process of documenting their constructions. The understanding of the project, and the structure and the genesis of the solutions depend on good documentation skills. There is a strong link between the quality of the analysis and the decomposition of the problem to be tackled and the ability to communicate those problem parts and their solutions at different levels of abstraction. It is therefore extremely important for students to learn to write well-structured and understandable documents. Our experience with DBL confirms that it is a skill that does not come naturally to many of them (also reported elsewhere, [5]). It is thus clearly important to make the acquisition of this skill a priority and DBL provides plenty of opportunities to train it. Accordingly, although not visible in Table IV, the decision was made to give more attention in the courses parallel to the DBL-projects, to the discipline-related aspects of the software documenting process. Examples of such skills are: making understandable program code to the maintainer or peer, and constructing a user manual. The attention is repeated in the SE project. In the next paragraph we will reflect on these changes and formulate some concluding pieces of advice for colleagues in the similar situation of implementing project work with a set of skills. International Conference on Engineering Education
July 21-25, 2003, Valencia, Spain 3
REFLECTIONS ON CHANGE We will reflect on three aspects of change in our program: the change of the function of a skill (micro level), the developmental stages in our skills training program (macro level) and at the way in which decisions to change have been made (meta level). Firstly, we consider the function of a skill. Many general skills can have two functions in the curriculum: a skill can be a goal or it can be a means (or even both). As an example, we look at the skill of assessing peers. In our program it was introduced as a means to involve all members of a project group more equally in the work to be done. Later on, it was stressed that assessing peers is an academic skill, worthy in itself. So, the skill of peer assessment became a goal as well as a means. As another example, we take the skill of writing. Students can learn the skill of writing a report as a goal or they can learn a subject by writing about it [5]. In the second case, writing is a means to learn the subject matter. And students can learn the skill of team work and learn to interact with each other in an efficient way; on the other hand, learning through interaction can be very fruitful under the right conditions, see [6], [7], [8]. Finally, every one of us has had the experience of deep learning while preparing a presentation, the other side of the skill of presentation itself. It is important to be aware of these ‘didactical conversions’ of skills and to use their potential. In our experience, it is easier to convince the teaching staff of the importance of the goal function of a skill compared to its means function. Secondly, we look at the development of our skills program as a whole. Looking back we can identify three stages in its development: • Isolated and limited skills training: this proved to be not very effective. • Project work with too much skills training diversity: this was a stage of ‘skill overkill’; too much skills training can lead to time consuming overhead in educational project work, especially when the small project context is unnatural for the activities concerned. All sorts of useful professional activities only have value in the context of complex and lengthy projects, projects with a critical mass. • Project work with selected skills training: the core skill in this last stage is reporting in a broad sense. It is our conviction that this should be the core skill for all computer science programs. To what extent this should be the core skill for other engineering programs, is outside the scope of this article. Of course, we are not in the position to conclude whether the third stage was the final stage or not. Skills are still under discussion. For instance, concerning the core skill, the training of report writing has to be evaluated. And, concerning the skill of time management (see Table IV), the project coordinators do not yet agree on the following point: should this skill be learned by keeping a log including design process decisions or should these decisions be documented elsewhere? Thirdly and finally, let us discuss the way in which decisions about change were made. The decision to introduce Design Based Learning was made at a central level and even to some extent forced upon the program of Computing Science. Nevertheless, the implementation was fairly successful, certainly in comparison with some other programs. In [2] the fact that Computing Science had a problem, the skills problem, is described as an important factor for this success. In some other programs DBL did not have such an effect, because this problem had already been solved in another way. An innovation needs some problem to be solved [2]. Looking back at our changes to the skills program, we also notice that while some changes were rational and based on educational experience, there were also changes influenced by other, sometimes even accidental factors. For instance, in the second stage, a professional trainer taught the skills of progress control and quality management. When he left to a position outside the university, the shortage of funds for taking in new staff stimulated the decision to diminish attention for these skills. Also, in discussions, the influence of the opinion of a project coordinator could depend more on his or her status in the organization than on project work experience. The literature also indicates that there are other models describing innovation besides rational ones (see [9]). Universities are complex organizations. A decision process sometimes is characterized best as a melting pot, with streams of problems, solutions, participants and opportunities for making choices. And sometimes ‘solutions’ are merely answers looking for a problem, than the other way around: the ‘garbage can’ model [9]. Or, according to another model, a chaotic non-linear view of innovation: “One cannot mandate what matters, change is a journey, not a blueprint” [9]. It is important to be sensitive to these aspects in an innovation process and go along with them in a pragmatic way.
CONCLUSIONS Our experience with skills training in our curriculum has taught us several lessons. Skills should be trained in an integrated way. Only skills training which fits in naturally should be incorporated in students’ projects, or, vice versa, projects should be designed around skills. Useful professional skills can be perceived as time-consuming overhead if projects are not complex International Conference on Engineering Education
July 21-25, 2003, Valencia, Spain 4
enough. It is important to define a core skill; for Computing Science the core skill is reporting. Skills can have various functions in a program: they can be a goal or a means or both and this function can change. A process of curriculum development is not a totally rational process; it has some partly irrational aspects too.
REFERENCES [1]
Wijnen, W.H., “Towards Design-Based Learning”, OGO-brochure, No 2, Educational Service Centre, Technische Universiteit Eindhoven, 2000 [Dutch version in 1998].
[2]
Perrenet, J.C., “Innovation in Progress; Design Based Learning at the Technische Universiteit Eindhoven”, 26th International Conference LearnerCentered Universities for the New Millennium, Johannesburg, South Africa, 2001.
[3]
Perrenet, J.C., Mulders, D.J., "Collaboration and Design Based Learning; Why Can’t Faculties Do What Students Can?”, 27th International Conference Learner-Centered Universities for the New Millennium, Vilnius, Lithuania, 2002.
[4]
Krasniewski, A., “Teaching Technical Communication – Unexpected Experience”, Proceedings of the International Conference on Engineering Education, Session 6B3, Oslo/Bergen, Norway, 2001.
[5]
Feldgen, M., Clua, O.; Fostering Writing Habits in Computer Science: a Road to Meaningful Learning, Proceedings of the International Conference on Engineering Education, Session 8B3, Oslo/Bergen, Norway, 2001.
[6]
Springer, L. Stanne, M.E. & Donovan, S.S.; “Effects of Small-Group Learning on Undergraduates in Science, Mathematics, Engineering, and Technology: A meta-Analysis”, Review of educational research, Vol. 69, No. 1, 1999, pp. 21-51
[7]
Johnson, D.W., Johnson, R.T., Smith, K.A., “Cooperative Learning: Increasing College Faculty Instructional Productivity”, ASHE-ERIC Higher Education Reports, No. 4, 1991.
[8]
Perrenet, J.C., Bouhuijs, P.A., Smits, J.G., “The Suitability of Problem-based Learning for Engineering Education”, Theory and Practice, Teaching in Higher Education, Vol. 5, No 3, 2000, pp. 345-358.
[9]
Land, R., “Agency, context and change in academic development”, The International Journal for Academic Development, Vol. 6, No 1, 2001, pp. 4-20.
FIGURES AND TABLES TABLE I PROFESSIONAL SKILLS IN THE COMPUTING SCIENCE CURRICULUM Group skills Meeting, functioning in a team Communication skills
Reporting and presenting, in Dutch as well as in English
Project skills
Time management, progress control, quality management, project planning, setting up project teams, reviewing and inspecting program representations
Design skills
Analyzing, reverse engineering, data modeling, process modeling, object oriented modeling specifying, design and construction of algorithms
TABLE II CONTENTS OF SIX DBL PROJECTS Year. Subjects trimester 1.1 General orientation/ modeling 1.2 Specification 1.3 Machine controlling 2.1 Computing science core 2.2 Business information systems 2.3 Technical computing science
Design skills Analysis/reverse engineering/data modeling Specification Design Algorithmics Process modeling Object oriented modeling
TABLE III THEORY AND PRACTICE OF SIX DBL PROJECTS Year. Theory trimester 1.1 Data modeling 1.2 Specification formalisms and stepwise refinement 1.3 Automata and correctness of programs 2.1 Algorithmics 2.2 Specification and simulation of processes 2.3 Distributed design and graphics
Practice Construction of database applications Construction of specifications Construction of an automatic assembly line Selection and implementation of algorithms Simulation and implementation of a virtual enterprise Distributed game implementation
International Conference on Engineering Education
July 21-25, 2003, Valencia, Spain 5
TABLE IV SKILLS PROGRAMS 2000/2001 AND 2002/2003 Program 2000/2001 Skill 1.1 1.2 1.3 2.1 Group meeting T Writing a report S Giving a presentation S Giving a demonstration S Functioning in a project team T Writing a report in English S Presenting a poster in English Taking an interview Documenting software Time management T Progress control S Quality management S Project planning S Starting off project teams Software reviewing S Making using of an expert S Collecting information S Peer assessment -
2.2 T S -
2.3 S S -
other T T T T T T -
International Conference on Engineering Education
Program 2002/2003 1.1 1.2 1.3 2.1 T T S T R R T S S S S S S S S
2.2 R T -
2.3 R -
other S T S S T T T T T T -
July 21-25, 2003, Valencia, Spain 6
