The engineering of engineering education: curriculum development ...

European Journal of Engineering Education Vol. 31, No. 2, May 2006, 215–226

The engineering of engineering education: curriculum development from a designer’s point of view1 OTTO ROMPELMAN*† and ERIK DE GRAAFF‡ †Julianalaan 155, 2628BG Delft, Delft, The Netherlands ‡Delft University of Technology, Delft, The Netherlands (Received 25 January 2005; in final form 4 October 2005) Engineers have a set of powerful tools at their disposal for designing robust and reliable technical systems. In educational design these tools are seldom applied. This paper explores the application of concepts from the systems approach in an educational context. The paradigms of design methodology and systems engineering appear to be suitable for both analysing existing education and designing new curricula. Keywords: Curriculum design; Systems approach; Output oriented education; Assessment

1.

Introduction

Usually, in their professional careers, engineers are often involved in design projects. Their training prepares them to approach design problems in a systematic way. In most cases they learn to apply a systems approach and to use a specific stepwise methodology, analysing the objectives and planning alternative solutions to reach the desired goal (Roozenburg and Cross 1991). The development of a new course programme or the innovation of an existing curriculum can also be seen as design task (Romiszowski 1981, Waks 1995). Surprisingly, engineers seldom put their design skills into practice when they are faced with the task to develop a new course programme or the innovation of an existing curriculum. In particular within the framework suggested by the recent trends of output- and competence-oriented curricula, a design approach could be most useful. In this paper we will outline a general systems approach and design methodology. Next, we will discuss the consequences of applying this method to curriculum design in engineering education.

1 The paper is based on an invited lecture by O. Rompelman at the International Symposium on Engineering Education, Valladolid, October, 2004. *Corresponding author. Email: [email protected]

European Journal of Engineering Education ISSN 0304-3797 print/ISSN 1469-5898 online © 2006 SEFI http://www.tandf.co.uk/journals DOI: 10.1080/03043790600567936

216

O. Rompelman and E. de Graaff

2. The systems approach to education 2.1 Introduction The concept of systems has been of great help in both understanding the world around us and in modifying our environment so as to meet our needs. Not only in the ‘hard sciences’ and engineering, but also in medicine, biology, politics and economics the systems approach has proven to be extremely useful. A system can be defined as a part of the real world, conceived as being an entity with well-defined interactions with its environment. If the system is defined and described in whatever way, we may refer to it as a model. The impact of the environment on the system (dotted arrows in figure 1) is considered to be the input and the impact of the system on the environment (solid arrows in figure 1) is considered to be the output.

Figure 1. The system in its environment: input and output interactions.

The systems approach is used in both analysis of the existing world and synthesis of ‘a new world’ (artefacts, procedures, services). In analysis a part of the real world is considered as a system and the interactions with the environment are experimentally verified. This is the application of the systems approach in science, economy, physiology, etc. In technology, however, the systems approach is used as a tool to help to design something new. The interactions with the environment are intentional and can only be estimated by simulating the system, but ultimately can be verified by realising the system. Interactions with the environment in this case are somewhat more complex and consist of desired (intentional) interactions and spurious (unintentional) interactions (figure 2). Obviously, the simulation step is highly important in order to avoid any undesired behaviour before realising the actual system: simulation can help us to predict the behaviour of the system once it is realised.

Figure 2. A system with unintended interactions with the environment.

Curriculum development

2.2

217

Basic descriptions of the educational process

Teachers in higher education are highly qualified professionals with a scientific training. Yet, Van der Vleuten (1997) comments that in their capacity as teachers they seem to ignore scientific insights. He observes that university professors appear to prefer intuition to proven facts when it comes to their approach to teaching. Something similar applies to engineers in relation to choices in curriculum design. As the systems approach can be applied to all sorts of design problems, it makes sense to apply this method also to curriculum design. However, we have not been able to identify examples of such an approach. If a systems approach is adopted to describe the process of educational development, we have to define clearly the input and output as well as the actual process of teaching and learning. This process will be referred to as the educational process. Education can be considered as a process that transforms a student into a graduate student. The input and output quantities are attributes of the student and can be described in terms of knowledge, skills, understanding, etc. (figure 3).

Figure 3.

Education as a transform of the students’ attributes.

The process itself can be described as the sum of all activities of the institute of education, such as giving lectures and organising laboratory experiments. In this context the student is rather passive. He/she has a number of features: the educational process changes these features into other features. This is a rather traditional but still common approach to education. Many teachers consider it their main duty to transfer knowledge to the students. In this view the accent is on teaching, rather than learning. Presently, it is more common to assume that knowledge is not transferred but that the learner himself constructs knowledge on the basis of prior knowledge and additionally acquired information. The information can be acquired from written material (books), lectures, experience (laboratories, projects). This view is referred to as constructivism (e.g. Jonassen et al. 1998). In this vision the student plays an active role. As a consequence, figure 3 can be modified into figure 4, in which the process is a learning process with teaching as a facilitating condition.

Figure 4.

Learning as a transform of the students’ attributes.

Although this model is clear, it is hard to make it operational in the context of designing education. Three questions come up immediately. • How do we describe the input, i.e. what are the features of the student prior to the learning process (course, module)? • How do we describe the output, i.e. what are the features of the student after the learning process (course, module)? • How do we describe the learning process?

218


All three questions are relevant for any institute of education. Although in this phase of the discussion these questions are still open, we may observe some interesting and attractive properties of this approach. First, input and output features are analogous: it concerns issues like knowledge, skills, understanding, etc. Second, we may break up the process in constituent processes. A useful example is the reform of a traditional engineering curriculum into a Bachelor–Master-structure. The Bachelor–Master structure as it has been agreed upon in the Bologna declaration is a typical example of the ‘cascading’ of educational programmes, as is shown in figure 5. In this figure it is illustrated that Bachelors from one university might enter a Master programme of another university and that external Bachelors may enter into a different Master programme.

Figure 5.

Connection between Masters and Bachelors programmes.

The key problem is the connection between the two programmes, or, in other words: the (mis)match between the features of the Bachelor graduated in one university and the expected features for a Bachelor to enter the other university; this will be discussed in more detail. 2.3 Input versus output description of education For a further discussion of the problem of matching Bachelor and Master programmes we introduce a model (figure 6), which can be considered as an alternative version of figure 4.

Figure 6. The student as a ‘learning processor’.

In this diagram it is assumed that the student transforms the teaching into knowledge, skills and understanding. As mentioned previously, this reflects a traditional view on education. When a teacher is asked to describe his module, he will start by giving the name of the module. Next, the contents will be described on the basis of the material used (books, lecture notes). Similarly, a curriculum is described on the basis of the contents by summing up the modules. In fact, this is a description of the input of the process as depicted in figure 6. We only know something about the output, if we know what the student has done with the educational opportunities. The information on the output is based on a description of the input, an assumption of the student behaviour and a, usually rather poor, verification. This can be illustrated with a well-known remark, ‘They should know this, because I have told them in my lecture’. This remark is a statement on the output of the process (‘They should know this . . .’) on the basis of knowledge of the input (‘. . . I have told them in my lecture’) and an assumption of the learning process.


219

Obviously, this approach will lead to problems if educational processes are cascaded as was mentioned in the BSc–MSc example (figure 5). As a consequence, we should focus on the output of the process, which implies a description of the features of the student after having been subjected to the educational process. In such a context the assessment of learning results turns into an important mechanism to direct students behaviour (De Graaff 2004). Nowadays this approach is referred to as output-oriented education (figure 7). A full discussion on this issue is beyond the scope of this paper. For detailed information we refer to results of the SOCRATES Thematic Network E4 (Borri and Maffioli 2003, Heitmann 2003).

Figure 7.

Input versus output description of education.

As an example, in figure 8 the relation between input and output oriented education is depicted for an example taken from electrical engineering.

Figure 8. The relation between input- and output-oriented curricula.

Output description may just seem like something new and fashionable. However, due to internationalisation this approach is becoming more and more important. Two important aspects are: • Internationalisation of education: students, who, after having acquired a BSc degree, want to ‘migrate’ from one university to another, need a clear understanding of the required qualifications for further study. Similarly, universities offering Master programmes have a need for detailed information on the knowledge and skills of incoming students.

220


• Internationalisation of the labour market: graduates from universities all over Europe may enter the European labour market. Therefore, employers also need to know what the qualifications of graduates exactly are. A preliminary conclusion from this discussion is that, if we design education, the emphasis should be on the envisaged output features of the graduates. When thinking in terms of design, this conclusion is not surprising. Obviously, systems are designed to arrive at a well-described situation; in this case, this implies the attributes of the student after having been ‘subjected’ to the educational process.

3.

Feedback structures

So far we have described the educational processes as strictly ‘feed forward’ processes. This implies that we have not yet included any method of verifying whether the objectives (the envisaged learning outcomes) are indeed realised. Or, in engineering terms: the system lacks feedback. To discuss feedback an alternative version of figure 4 is used. We define the input of the educational process as the envisaged features of the graduate and the output as the actually realised features (figure 9). This process is suitable for including feedback since both input and output are of the same nature (i.e. features). In terms of control engineering the input is the ‘set point’ (‘reference value’) and the output the ‘controlled variable’. In order to introduce feedback we need measurements. In education this implies, e.g. examinations, etc., or, more generally formulated: assessment instruments (De Graaff 2000).

Figure 9. Assessment of education: measurements.

If the result of the assessment is not satisfying, it is usually assumed that the students did not acquire the envisaged features. However, this conclusion may be questionable. Very often the assessment does not really verify whether the teaching objectives are met. Students are often very smart in solving problems without a good understanding of the underlying theory. Also, it may be that the teaching objectives are not realistic. We may try to teach a blind person to read, but he will fail in any test! Finally, the teaching and learning environment may be poor: poor lectures, bad books, inadequate laboratories, etc. Therefore, if we want to extend the educational process to a controlled process, we need to include different feedback pathways. In figure 10 these pathways are depicted. The feed back pathways are: I: II: III: IV:

adjustment of assessment method adjustment of students’ activities adjustment of teachers’ activities adjustment of envisaged features


221

Figure 10. The role of assessment for feedback in the educational process.

As in technical systems, we have to take care of issues like time constants, gain factors and signal-to-noise rations of the individual control loops. It can be concluded that assessment plays a key role in educational systems, not only for the students but also for the management of education (Rompelman 2000).

4.

Design methodology

4.1 Basic methodology for designing technical systems It is well known that the successful design of technical systems requires a highly structured approach. Such an approach is usually referred to as a methodology. The methodology applied in this paper is the concept of design as problem-solving (figure 11). In this concept it is assumed that the designer observes a part or an aspect of the real world. His observations lead to his image of a part of the real world. Apart from the observed world he has ideas about what he thinks the real world should be, in other words: an ideal image of reality. Now he compares the observed world and his ideal image of the world. This comparison leads to the definition of a problem. Solving this problem is accomplished by creating ‘something’ (a product) such that the world will look more like his ideals. In the optimal situation the real world will equal his ideal image.

Figure 11. The paradigm of the design process: design as solving a problem.

222


Another aspect of design is its predominant role in the life-cycle of products or, more general: (technical) systems. The consecutive phases of the life cycle are shown in figure 12. These phases are rather logical and do not need a further discussion.

Figure 12. The life-cycle of technical systems.

The design phase comprises all preparations before actually creating something. Figure 12 depicts that in the design phase it is necessary to take into account all aspects related to all phases of the product to be designed (production, usage, management, maintenance, recycling/disposal). The designer has to contemplate on all these issues when designing a system. In practice, this means that he has to think about the future: he should try and formulate (a) questions like: • • • • • •

Can it be implemented and how? Can it be used and how? Can we verify whether the systems does what it should do and how can we do this? What are the costs involved? What is the environmental impact? How long should the system be in operation (life-cycle) and what do we do after its life-cycle has come to an end?

All these considerations will contribute to a set of design criteria; this set is referred to as the ‘Product Requirements Plan’ (PRP), which is the result of phase B in figure 13 (ten Haaf et al. 2002). In fact, the requirements imposed by the reflection on ‘the future’ lead to a set of boundary conditions in the PRP. 4.2 The Product Requirements Plan (PRP) The Product Requirements Plan (PRP) plays a key role in the design process. Here the influence of aspects of all phases of the life cycle as depicted in figure 12 becomes apparent. The PRP comprises two main issues: 1. The function of the system (what it is supposed to do). 2. The boundary conditions. These boundary conditions are a translation into operational terms of all wishes, preferences and requirements as formulated by all people involved (manufacturers, users, operators, etc.). It is important to note that this translation is the full responsibility of the designer.


223

Two types of boundary conditions can be distinguished: 1. Hard conditions: these conditions should be met (yes/no decision). 2. Soft conditions: these conditions are met ‘to a certain extent’. Any valid conceivable solution must meet: • functioning criteria: describing (primary) function, • ‘hard’ boundary conditions. The conceivable solutions may meet the ‘soft’conditions in different ways: this leads to options for choice! 4.3 The design phase elaborated The design phase can now be elaborated as shown in figure 13. As can be seen from the figure the subsequent phases are not unidirectionally related. This reflects the dynamics of the entire process in which it is allowed (and sometimes even advisable) that in the process we may return to a previous phase, if we discover that assumptions in a previous phase appear to be erroneous.

Figure 13. The design phase in detail.

There are five essential steps in the design phase. 1. Define the problem. 2. Define criteria to be met by the solution: reflection on ‘What do we want?’, rather than ‘How do we want it?’; this leads to ‘Product Requirements Plan’ (PRP). 3. Develop different concept systems (solutions); usually, a problem has more solutions than just one! 4. Simulate concept solutions: evaluate the concept systems, leading to the Product Requirements Plan (PRP) and choose the most promising concept system. 5. Select the best solution according to criteria (see 2).

5.

Consequences for designing educational systems

In the previous sections we have discussed the systems approach to (engineering) education as well as a general framework for design. In this section a basic framework for curriculum design is discussed. The phases as depicted in section 4 (figures 12 and 13) can be made appropriate for the educational setting. This leads to the following characterisation of the five steps: I. Problem analysis. In relation to what has been discussed previously, the educational problem should be defined in an output-oriented way. So, it should not be defined as ‘in our

224

II.

III.

IV.

V.


program we need a course in mathematics’ but ‘in our program the students need a module after which they have acquired the following skills, knowledge, competencies:…’. In fact: what the module is envisaged to achieve. Definition of requirements. Similarly to the PRP of engineering products we can define a Course Requirements Plan (CRP). The main issue in this CRP is the educational problem as mentioned above. Consequently, criteria have to be defined, to be met by the solution. The following four categories can be identified: 1) About the learning outcomes: • the outcomes should be realistic given the attributes of the target group (prior knowledge skills) and the time available for the students (credit points!), the outcomes should be testable; if not, they should be left out or reformulated. 2) About the preparation and production (planning) staff time (costs!) development of course material, assessment arrangement of laboratories, computer rooms, etc. 3) About running the module/course/programme • staff time, • infrastructure: rooms, laboratories, equipment, communication, office hours, web-support, e-mail, . . . 4) About the life-cycle life span of the module/course/programmere-use of (parts) of the module/course/programmein time discussion of prolongation, modification of the module . . . The fact that the latter issue is taken into account implies that right from the beginning it is assumed that the course will not last forever. Creating concept solutions. Different educational systems may be proposed that may be suitable for solving the educational problem as previously defined. These imply lectures, laboratories, working groups, projects and/or combinations of these. Simulation of concepts. Simulation in its mathematical or technical sense is usually very difficult since it involves people. This means that other ways of predicting its behaviour should be employed. It can be observed in practice that many educational systems (programmes, curricula, courses) are designed and implemented without a thorough prior analysis (i.e. estimation) of how the system will work once implemented. Evaluation and final choice. This is a crucial stage in the process. Here, final decisions have to be taken, obviously, on the basis of the CRP. Often, conflicting interests become apparent and good management and leadership is required to arrive at a wise decision. Once the decision is taken the design phase is ended and the implementation starts.

Although the CRP plays a crucial role in the design of education, its impact reaches beyond the design period. The CRP serves four functions: 1. It provides the framework for designing an educational system. 2. It is a frame of reference to test different concept solutions (concept systems) in order to find the most promising solution. 3. It is a framework for verifying the resultant educational system. It provides the basis (reference criteria) for the quality management of the education. This latter issue has to be related to the assessment structure as discussed in section 3. As is often the case in education (but also in technical systems), in the course of the application of the system, the expectations may change. Teachers of follow-up courses may have a different view on the outcomes. In particular, this is a problem with input-oriented modules! Also, the original environmental conditions may change: less money, less staff, changing attributes of incoming students, etc. In that case the CRP is a useful frame of reference that is extremely useful for keeping possible discussions sound and to the point.


6.

225

Conclusions

The main thesis of this paper that educational design could benefit from applying successful methods of engineering design is supported by presenting an analysis of international student exchange in Europe. The systems approach helps to identify the weaknesses in the traditional curricula. Even more useful, the systems approach could be applied to the challenge of (re-) designing engineering education. The present process of unification of Engineering Education in Europe started off by the introduction of the Bachelor–Master structure makes it reconsidering our educational processes inevitable. Goals have to be redefined and courses and curricula will have to be adapted or even restructured. The application of the paradigms of systems theory, including the concept of feedback, may clarify and structure the processes involved. The engineering sciences have developed powerful tools for a systematic approach to the design process. In summary, a reflection on these tools leads to the following observations. • The development of curricula/courses can be approached as a design problem. • As with technical systems, a detailed and well-structured ‘Course Requirements Plan’ CRP) has to be formulated. • The main aspect of the CRP is: envisaged learning outcomes. • Other issues to be taken into account are:envisaged life-time, ◦ required infrastructure (staff, rooms, laboratories, etc.), ◦ assessment procedures, incl. quality control. The systems approach can be enlightening in curriculum development These engineering tools, combined with the logical application of the systems approach, could be highly valuable in curriculum development. References Borri, C. and Maffioli, F., Thematic Network E4: an effective tool to improve EE in Europe Eur. J. Engng Educ., 2003, 28, 425–434. De Graaff, E., Assessment and Educational Development. Report for Aalborg University, 2000 (Aalborg, Denmark: Videncenter for Laereprocesser Aalborg Universitet). De Graaff, E., The impact of assessment on the problem-based learning process. In: Challenging Research in Problembased Learning, edited by M. Savin-Baden and K. Wilkie, pp. 26–36, 2004 (Glasgow: Society for Research into Higher Education & Open University Press). Heitmann, G., Innovative Curricula in Engineering Education, E4 Thematic Network: Enhancing Engineering Education in Europe, Volume C, 2003 (Firenze University Press). Jonassen, D.H., Peck, K.L. and Wilson, B.G., Learning with Technology: A Constructivist Perspective, 1998 (New Jersey: Prentice Hall). Romiszowski, A.J., Designing Instructional Systems, 1981 (London: Kogan Page/New York: Nichols Publishing). Rompelman, O., Assessment of student learning: evolution of objectives in engineering education and the consequences for assessment. Eur. J. Engng Educ., 2000, 25, 339–350. Roozenburg, N.F.M. and Cross, N.G., Models of the design process: integrating across the disciplines. Design Stud., 1991, 12, 215–220. ten Haaf, W., Bikker, H. and Adriaanse, D.J., Fundamentals of Business Engineering and Management, 2002 (Delft: Delft University Press). Van der Vleuten, C.P.M., De intuïtie voorbij [Beyond Intuition]. Tijdschrift voor Hoger Onderwijs, 1979, 15(1), 34–46. Waks, S., Curriculum Design: From an Art towards a Sscience, 1995 (Hamburg: Tempus Publications).

Notes on contributors Otto Rompelman received his MS. in Electrical Engineering (1969) and his PhD (1986) from the Delft University of Technology (Netherlands). He has worked in the field of biomedical

226


signal and image processing for about 25 years. He has published about 50 papers and book chapters and co-edited two books on the analysis of heart rate variability. As a member of the board of the Faculty of Electrical Engineering TU Delft (1991–1992), he was responsible for the introduction of a new curriculum. Since 1993 he has been active in different projects related to internationalisation and innovation of education in electrical engineering. He has been active in SEFI for about eight years (as a chairperson of the Curriculum Development Working Group). Since 2004 he has been a freelance consultant for higher engineering education. In 2004 he was awarded the SEFI Fellowship. Erik de Graaff is trained as a psychologist and holds a PhD in social sciences. In 1994 he was appointed as associate professor in the field of educational innovation at the Faculty of Technology Policy and Management of Delft University of Technology. He has published numerous papers on problem-based learning, project organised learning, student evaluation and educational innovations. He is an active member of SEFI (the European Society of Engineering Education). Since 2003 he is a chairman of the Curriculum Working Group (CDWG) of SEFI. In 2005 he was elected Vice president of SEFI.