Int. J. Networking and Virtual Organisations, Vol. 6, No. 2, 2009 Learning from achievement: scaffolding student projects in software engineering Bendik Bygstad* Norwegian School of IT, Norway E-mail: bendik.bygstad@nith.no *Corresponding author Birgit R. Krogstie Norwegian University of Science and Technology, NTNU Norwegian School of IT, Norway E-mail: birgitkr@idi.ntnu.no Tor-Morten Grønli Norwegian School of IT, Norway E-mail: grntor@nith.no Abstract: It has become almost a truism that students learn more from working on projects than from lectures. This is reflected in pedagogical approaches such as Problem-based Learning, Project-based Learning (PBL) and Work-based Learning. A problem in PBL, underrated in the literature, is that while trivial tasks hold limited potential for learning, students may not succeed in solving nontrivial ones. We suggest that the solution lies in appropriate scaffolding: providing support for the learner to gradually master what is needed to complete a task. The empirical background for the study is a two-semester Software Engineering (SE) course at the Norwegian School of IT, with data collected over five years. We conclude that PBL in this setting may be successfully scaffolded by a formal, iterative and incremental SE method. As our main contribution we point to six types of scaffolding addressing essential aspects of SE project work. Keywords: scaffolding; student projects; software engineering education. Reference to this paper should be made as follows: Bygstad, B., Krogstie, B.R. and Grønli, T-M. (2009) ‘Learning from achievement: scaffolding student projects in software engineering’, Int. J. Networking and Virtual Organisations, Vol. 6, No. 2, pp.109–122. Biographical notes: Bendik Bygstad holds a PhD in Computer Science from Aalborg University and a Master of Sociology from the University of Oslo. He is currently an Associate Professor at the Norwegian School of Information Technology. His main research interest is the relationship between SW development processes and innovation, and qualitative research methods. He has published articles in such journals as Information Systems Journal, International Journal of Project Management, International Journal of Technology and Human Interaction, Electronic Government and Software Process. Copyright © 2009 Inderscience Enterprises Ltd. 109 110 B. Bygstad, B.R. Krogstie and T-M. Grønli Birgit Rognebakke Krogstie holds an MSc in Computer Science from the Norwegian University of Science and Technology (NTNU) and a Master of Educational Theory from the University of Oslo. She is a PhD candidate at the NTNU in the area of computer supported cooperative work with a research focus on work and learning in software development project teams. Tor-Morten Grønli received a Master’s degree in Distributed Information Systems and Computing from Brunel University, Uxbridge, UK. He is currently a PhD candidate at the School of Information Systems, Computing and Mathematics at Brunel University, Uxbridge, UK, and a Lecturer at the Norwegian School of IT. His current research interests include software engineering, pervasive and ubiquitous computing, and context-aware systems. An earlier version of this paper was published at the NOKOBIT Conference in Molde, Norway, 20–22 November 2006. 1 Introduction It has become almost a truism that students learn more from working on projects than from lectures. Various pedagogical approaches, such as Problem-based Learning (Helle et al., 2006), Project-based Learning (PBL) (Markham, 2003) and Work-based Learning have contended that students learn more from solving real-world problems in a setting where the teacher no longer instructs, but acts more like a coach. We subscribe, in principle, to this thinking. There are, however, some inherent problems in the project-learning approach that are underrated in the literature. The most important one may be described this way: If the project task is trivial, the students will not learn much. If the project task is nontrivial and complex, the students will often not succeed in solving it, and learning from failures is both expensive and discouraging. We suggest in this paper that an effective strategy for solving this challenge is the careful application of scaffolding, with reference to Bruner’s original concept (Wood et al., 1976). In broad terms, scaffolding means to provide the necessary support for the learner to gradually master what is needed to complete a task. Used correctly, scaffolding increases the likelihood that the project groups will succeed in accomplishing a complex task, such as Software Engineering (SE). Our research is motivated by a pedagogic interest and relates to empirical data on actual courses collected over several years. Rather than testing a hypothesis, we apply an interpretive research approach to gain an understanding of a particular practice within SE education, and thereby contribute to the development of this pedagogical field. Our research question, then, is How can scaffolding be applied successfully in SE student projects? The rest of the paper is organised as follows: In Section 2 we present the main challenges of teaching and learning SE and our key concept of scaffolding. In Section 3, we briefly outline our research methodology and present our case. Then in Section 4, we present our scaffolding approach in detail and discuss our results. Section 5 concludes the paper and points to further research. Learning from achievement 2 111 Research review In this section we first discuss major challenges of SE education. Then we define and discuss the scaffolding concept. 2.1 Learning software engineering SE is an arena well suited to studying scaffolding, because it presents both the students and the lecturer with a number of challenges. SE is one of the most complex tasks man has ever set out to perform. Simplified, it may be described by two separate challenges. The first is to translate a real-world problem into a design for a software solution; the next is to actually build, test and deploy the solution into the real world (Brooks, 1987). Since the discipline was born in the 1960s, it has been well documented that building large information systems is a high-risk undertaking, demanding both technical and social skills. Even after 50 years of experience, the failure rates of software projects are still surprisingly high (Sommerville, 2001; Standish Group, 2001). The challenges of teaching SE reflect this situation. From a pedagogical point of view, the main objectives of a typical SE course are: • to integrate the knowledge and skills from various computer science modules • to teach the students the process steps and artefacts of SE. Both objectives represent real pedagogical challenges, because the first one is analytically quite demanding for the students, and the second one is – if taught as theory – excruciatingly boring. This has led to a number of innovative approaches. Most of them build on pedagogical principles from constructivist thinking (Vygotsky, 1978; Blumenfeld et al., 1991; Dewey, 1997); the students should ‘learn by doing’ (not by being lectured), they should construct a concrete artefact, they should work collaboratively (not individually) and the role of the teacher should be as a facilitator (not authoritarian). In SE courses, PBL has been reported to work successfully and is widely applied. For example, the annual Conference on Software Engineering Education and Training (CSEE&T) usually includes a track for SE projects. The PBL approaches share a number of attributes: they aim to present larger cases that emulate real-world problems, emphasise collaborative learning, aim at integrating knowledge from different parts of the computer science curricula, and also explore new relationships and roles between students and lecturers (Morrison, 2004; Gulbahar and Tinmaz, 2006). For example, Sindre et al. (2003) reports from a cross-course project that fully integrates four other disciplines at the NTNU in Norway, thus achieving a scaling effect to make the case more realistic. At the same time, pitfalls of collaborative systems development that may affect SE student projects have been identified, e.g., free riders, configuration management and time management (Morrison, 2004). 2.2 Scaffolding A pedagogical challenge for PBL in SE is that the task in itself is quite demanding, leading to a high risk of failure for the student groups. Reflection on the reasons for failure may generally be a source of learning, if there is an opportunity to try out new and 112 B. Bygstad, B.R. Krogstie and T-M. Grønli better ways of doing things in the next learning cycle (Dewey, 1997). In an SE project, there will normally be phases and/or iterations giving ample opportunities to reflect, learn and improve. Complete failure in the project is, however, likely to be detrimental to students’ experience harming motivation for further work and learning (Bandura, 1994). Further, learning in a project relates to a set of skills necessary to successfully complete the project. If serious problems prevent students from having any relevant experience with certain central SE tasks (e.g., because of dependencies with other, noncompleted tasks), the learning objectives of practising various skills might not be reached. We accordingly believe that the pedagogical design of an SE project course should have mechanisms to ensure a reasonably successful completion of the essential tasks involved in the SE project. What are the effective strategies for achieving this within the frames of PBL? Learning can be regarded as happening in a Zone of Proximate Development (ZPD). The zone describes the ‘space’ between what learners can achieve without help and what they can achieve with the help of a tutor or supervisor (Vygotsky, 1978). The skills and knowledge defined by the learning objectives of a PBL design may be found at the outer limit of the students’ ZPD as the project starts. As students learn throughout the project, with course staff providing support for them to reach beyond what they are able to do alone, the students’ skills develop and the outer limit of the ZPD expands. When a project course is completed, the successful completion of a (structurally) similar project may thus be attainable to the students without much staff supervision. Providing support for the learner to gradually master what is needed to complete a task has been denoted scaffolding by Bruner (Wood et al., 1976), who builds on Vygotsky’s work. Scaffolding was initially used as a metaphor for the process where an adult assists a child to carry out a task that is outside the child’s current capabilities. This allows the child to concentrate on the elements within reach, gradually increasing his skills. “At best, this process continues until he becomes acquainted with and skilled in all aspects of task activity, to the point where he can initiate and control his own behavior in the absence of an instructor” (Stone, 1993). In a higher education context, scaffolding includes activities such as providing directions, keeping the student on track, offering assessments, increasing efficiency and reducing risk. Scaffolding typically implies the use of artefacts like computers and documents. On one hand, such learning materials limit the students’ options in the learning process. On the other hand, the learning materials support the learning process by reducing sociocognitive load and implementing a learning agenda (Suthers, 2006). SE project courses vary in respect of requirements for students to follow a certain process model and, if a specific model is required, how many templates and guidelines are provided, and how strictly they should be adhered to. Iterative software development approaches represent current practice within SE (Jacobson et al., 1999; Larman, 2004), and thus many SE courses are based on iterative process models in order to provide students with sought-after competence. Requiring strict adherence to a process model within PBL might, however, raise questions about the necessary room for challenge and for developing individual approaches and solutions. Anticipating our conclusion, we argue, based on empirical data, that relatively structured iterations in student projects at a certain stage of SE education provide opportunities for scaffolding that greatly benefit learning results. Gradual mastery of the basic steps in conducting project tasks and producing project artefacts in the early phases of a project enables students to explore other equally challenging dimensions of project Learning from achievement 113 work. A structured process allows students to come up with (sufficiently) creative and unique solutions with little risk of getting lost in the basics of project artefacts, and with less risk of the whole project failing. 3 Method In this section we present our method and our case. 3.1 Method The empirical part of this research is a case study of an SE module in the Norwegian School of IT (NITH) from 2002 to 2006. Two of the authors were lecturers in the course. The course has been under continuous improvement. The experiences from each year were discussed with involved staff and external sensors at the end of the year. These views, supplemented with student evaluation results, were then fed back in the form of improvements for the next year’s running of the module. In 2006 we took a longitudinal view of the module, analysing the trends and patterns (Miles and Huberman, 1994). Data collection was performed with a number of sources: • Student and marking statistics and student satisfaction data constitute a quantitative resource. • The projects were very well documented by the student groups. Each project group wrote six iteration reports, a final project report, and also individual and group reflection notes. In particular, the reflection notes were a valuable source of information about the projects, because they described the learning process in detail, as experienced by the group and by each individual. The individual reflection notes were treated confidentially in the projects, and were quite open in describing the interaction between students. In the citations from this material, the quotes were translated from Norwegian. • Since two of the authors were also lecturers, participative observations of literally hundreds of tutoring sessions with project groups constitute an important part of our empirical material. We acknowledge the limitations in this type of ‘data’, and use these observations only as background. First, we analysed the student marks and student feedback data in the years 2002–2006. In addition, we analysed the comments given by students in their evaluation feedback sheets. This gave us a longitudinal view of the results. Then we reviewed in detail the reflection notes for 2005 and 2006, both group and individual notes. Each reflection note was usually between one and two pages, enabling us to do a detailed qualitative analysis of the issues identified as relevant for the topic of scaffolding. These included support for the main structure and microstructure of the project, the degree of perceived integration with other courses, challenges associated with product and document integrity, and collaboration within the groups. 114 B. Bygstad, B.R. Krogstie and T-M. Grønli 3.2 The SE course The NITH is a private university college in Oslo. Specialising in IT education, the college works closely with the industry to develop relevant courses, offering Bachelor programmes in IT and in SE. The PJ300 course was developed in 2001, with the aim of integrating the different courses of the second year of the IT Bachelor’s programme. These modules are Programming (Java), Databases (Oracle), Systems Analysis and Design (UML), Technology (Data communications) and Technology and Organisation. The structure of the Bachelor programme is shown (somewhat simplified) in Table 1. Table 1 Structure of Bachelor of IT programme 3rd year Programming or Systems analysis IT in organisations IT security Work-based project 2nd year Programming and databases Technology and organisation Technology Systems analysis 1st year Programming Databases Technology Systems analysis and projects Project SE engineering The main objectives of the PJ300 module were: • to provide a learning space for the students to integrate the knowledge and skills from the other five modules • to teach the students the basic skills of SE. As described in the introduction, both objectives represent real pedagogical challenges. Our strategy to meet these challenges was to provide the students with a large software development case, large enough to last a year and including knowledge and skills from the other parallel modules. The case needed to be constructed in such a way that students at all levels of skill would be comprehensively challenged. In our case, this could be achieved by requiring the project groups to apply UML and patterns (Larman, 2001) in analysis and design, to programme the software solution in Java and Oracle, and run it in a complex environment of PCs, a database and web servers. At the start of the second Bachelor year, this challenge is way above the skills of the students, and the project was designed so that teaching in other parallel modules provided the students with the necessary skills just in time for the project. To structure this development process, we chose the Rational Unified Process (RUP). There were two reasons for this choice. First, RUP is a modern and widely used SE framework in the IT industry, thus supporting NITH’s aim of working closely with industry. Second, RUP provided a quite extensive set of guidelines and templates for the development process (Jacobson et al., 1999). The number of students (decreasing annually, because of the general decline in the number of IT students in Norway) and the specifics of the case during the five years of operation are described in Table 2. 115 Learning from achievement Table 2 Number of students and project case Year Number of students 2002 632 Case New technology introduced Airline tickets Java 2003 379 Hotel and activities booking Java servlet 2004 255 Airline tickets Web services 2005 102 Web-based exam test system WAP application 2006 71 Sushi restaurant order system J2ME application Sum 1439 The structure of the project year is detailed and mandatory. The case is given by the course leader, and is quite detailed, describing the system in five modules. The groups are free to choose how many of the system modules they intend to develop, the modules being increasingly demanding. The more modules that are successfully developed, the better the achievable grade on the result. The structure of the project year is shown in Table 3. In the first week, the students fill in a form addressing personal motivation and technical skills. Based on these data, the course staff form relatively homogeneous student groups of four. A key feature of PJ300 is that it follows an iterative structure. The project is structured by six iterations, in accordance with RUP. Each iteration is a ‘mini project’, starting with objectives and requirements, proceeding with design, programming and testing, and ending with a formal meeting with the ‘customer’, i.e., the tutor. Each iteration is done in a one-week block, where the students work during the full week with the project. Table 3 Structure of PJ300 during the year Course part Autumn semester Spring semester Exam Week Iteration Artefact objective 34 1 Project plan and GUI prototype 41 2 Draft SW architecture, application module 1 50 3 SW architecture, application modules 1+2 3 4 Application modules 1+2+3 9 5 Application modules 1+2+3+4 (+5) 16 6 Finished application 20 Product demo Each iteration is documented in a short report, UML models, source code and iteration plans. The iteration result is deployed at a website maintained by the group during the project. At the end of the spring semester the students post their final report and reflection notes, and then the website is closed and made available for the two censors. In the exam the students present their work orally and demonstrate the completed application. The censors pose questions on both process and technology, and give final feedback and grades. 116 4 B. Bygstad, B.R. Krogstie and T-M. Grønli Findings and discussion This section presents the findings from our case study. Our main finding is that various types of scaffolding have been proven effective for learning in this project. We will systematically present and discuss these types. 4.1 The results of the course The results of the PJ300 have been quite good, as shown in Table 4. Table 4 Results of PJ300 Year A B C D E F 2004 36% 35% 2005 38% 34% 22% 5% 2% 1% 14% 12% 2% 2006 25% 45% 15% 14% 2002/2003* Note: * Norway changed its grading system in 2004, so grades from 2002 and 2003 are not commensurable. The profile, however, is the same as for the following years. The quite satisfying results shown in Table 4 are even more impressive when we take into consideration that the actual students of NITH have medium to low grades from high school, and also much poorer results in the programming modules than in the project course. We should, however, add that projects generally achieve better marks than other courses partly due to the ‘free rider’ phenomenon. The results from the students’ feedback evaluation sheets give the same picture. Students have consistently given quite high satisfaction scores. The maximum score is 6 (very satisfied) and the lowest is 1 (quite unsatisfied). For 2005 and 2006 the scores are as shown in Table 5. Table 5 Student evaluation results Year* Content and relevance Lecturer Exercises My own learning Overall assessment 2005 5,2 5,1 3,9 5,2 4,8 2006 5,8 4,3 4,3 5,8 5,4 Average NITH 4,5 4,4 3,7 4,0 4,0 Note: * The student feedback was not measured the same way before 2005. It is notable that while the scores for content/relevance, my own learning and overall assessment are significantly higher than the NITH average, the scores for lecturer and exercises do not show better results. 4.2 Our scaffolding explained in detail We attribute the good grades and high degree of student satisfaction to various types of scaffolding, listed below: Learning from achievement • The main structure (phases and iterations) is scaffolded by RUP. • The microstructure (activities) is scaffolded by RUP. • Technical development is scaffolded by other courses, as shown in Table 1. • Product integrity is scaffolded by predefined product modules. • Document quality is scaffolded by predefined document structure and web-based hand-in and assessment. • Group cooperation is scaffolded by homogeneous groups and role definitions. • Lecturers and supervisors are providing and timing the scaffolding activities. 117 4.2.1 Main structure (phases and iterations) is scaffolded by RUP Scaffolding may be supported both at a macro (structure) and micro (activities) level (Gutzdial, 1994). At a macro level the PJ300 is supported by the iterative structure of RUP, shown in Figure 1. RUP is structured in four phases, each consisting of one or several iterations, mini-projects with a clear objective. Figure 1 Structure of the Rational Unified Process (see online version for colours) Source: IBM Corp (2002) As described in the previous section, a key feature of PJ300 is that it follows an iterative structure. The structure of each iteration is relatively uniform through the six iterations. The students usually struggle with the first two iterations, but gradually the iteration structure is routinised and managed. One student group wrote in their reflection notes: 118 B. Bygstad, B.R. Krogstie and T-M. Grønli “We learned most by working with incremental parts which were developed in iterations. Using RUP helped us to go from theory to practice in a large project that was rather similar to an industrial project.” We propose that the repetitive character of iterations gradually increases the students’ confidence, in accordance with the principles of scaffolding described in Section 2. It is also congruent with Bruner’s notion of a ‘spiral curriculum’, where structural elements are repeated (Bruner, 1960). The SE method has in fact been utilised in other pedagogical settings as an iterative framework for learning. For example, in Spain, a course using the iterative and incremental structure of XP was used as a pedagogical technique, as well as a subject for the students (Alfonso and Botia, 2005). 4.2.2 Microstructure (activities) is scaffolded by RUP A software process such as RUP includes a main structure for a project (iterative and incremental), a set of artefacts to be produced (documents, models, components) and a sequencing of detailed activities. In professional SE this structure is established to achieve control over the development process. When implemented in a teaching context, does this impose restraints on the creative and exploratory learning process? Our evidence indicates no. In the first two years (2002–2003), we left the students free to choose how they wanted to use RUP, with options ranging from using only the main structure and improving the rest, to following RUP in every detail, using the textbook and RUP online as resources. The result was disappointing; the groups spent the first two iterations doing research and discussing RUP, and were not able to plan and manage productively. The groups’ discussions of RUP were generally poor, because they did not have any real experience using it. One student wrote: “What has not worked well was the start of the iterations. A lot of ideas came up, and we discussed a lot, which led to a late start.” We solved this problem through (from 2004) a strong structuring of the iteration plans and the definitions of artefacts. Instead of trying to make their own interpretation of RUP, the groups based their project planning on prespecified lists of activities and required artefacts. The result was quite successful, and the groups could work productively from the start. We also saw that less skilful students were able to be productive enough to deliver the minimum requirements and achieve a passing mark (or better) in the module. It is noteworthy that this did not stop the groups from reflecting on the weaknesses of RUP and criticising the framework at the end of the project. An example is the following quote from a student: “Although I do not have any experience with lightweight methods such as XP, I think they are more my style than RUP. I like to attack problems directly by programming. It is OK to draw models on paper and discuss it with others, but I manage fine without doing this.” Learning from achievement 119 4.2.3 Technical development is scaffolded by other taught courses The technical challenges of PJ300 are quite demanding for a second-year student. The students are asked to design and program a Java (web) application using a set of software design patterns. To succeed, the group needs skills in Java, web, database and data communications. In addition, the most ambitious groups develop a module for mobile technology, enabling them to communicate with the system using a mobile phone. Here are two typical comments: “The design patterns we are learning in systems design were quite useful. Initially, I thought these patterns were just crap, but in fact there were a number of useful points there.” “In the beginning, the assignment seemed to be very large and complex, but throughout the year we have had lectures in programming and design which made it possible to solve the project case. These lectures were well-timed for using the knowledge in the following project weeks.” The modules that teach these skills are delivered in parallel with the project. In the period when the students need skills in Java servlets, the Java course is scheduled to teach this subject. Thus, when meeting a problem, they may also ask the lecturer in another module for guidance. 4.2.4 Product integrity is scaffolded by predefined product modules Before the project is launched, a predesigned solution is built by the staff to act as a basis, the initial scaffold. The solution addresses the learning outcomes in the module and represents one among many possible ways of solving the case. The solution should possess a quality that makes it useful as a pedagogical tool for the staff, whether in direct supervision of the projects or in teaching-related courses. We ensure this quality by making the ‘layers pattern’ (Larman, 2001) as a foundation for the architecture. One comment from an individual reflection note: “I have reached a deeper understanding for how different technologies together constitute a whole product. Throughout the project new challenges have emerged which had to be solved. This has greatly increased my learning.” Students aiming for the most advanced deliverables will not be left trying and failing. Rather, the product integrity in the advanced parts is scaffolded by the provision of a product skeleton that can be built upon and that directs a path for the students to follow. 4.2.5 Document quality is scaffolded by predefined document structure and web-based hand-in and assessment All artefacts are documented on the group’s website from the start of the project, and at the end of the project the result is given a grade. The structure of the website is defined from the start of the project. As noted by Gulbahar and Tinmaz (2006), the website has several benefits. First, it gives both the project member and supervisor easy access to the materials, even from outside locations. This is important during a long project, during which some students may be ill or travelling abroad. This also eases the collaboration and sharing of information within the group by enabling easy, location-independent access to all 120 B. Bygstad, B.R. Krogstie and T-M. Grønli documentation. Second, the students can concentrate on the system development with its necessary documentation – and not on writing reports for the teacher. Third, a portfolio-based assessment emulates a real-world situation, thus supporting a central objective of PBL (Gulbahar and Tinmaz, 2006). Our experience is that the students are quite satisfied with web-based assessment. However, some lecturers and censors had objections to reading so much documentation on-screen, and asked for printouts. 4.2.6 Group cooperation is scaffolded by homogeneous groups and role definitions The composition of the group is important. We have experimented with different approaches, starting with heterogeneous teams (students with great differences in skill profiles), but concluding with homogenous teams. Ideally, a good project team is a heterogeneous one (Belbin, 1993), enabling the project members to contribute individually. However, in PJ300 this created a lot of tension during the first years, because the strong students could not accept that weaker students were given credit for work to which they did not contribute. A basic problem with PBL is free riders (Morrison, 2004), which is considered unfair and unacceptable also by Norwegian students. When such problems occasionally arise, there is a standard procedure with the possible outcome of exclusion. We reduced the free rider problem by making the groups as homogeneous as possible regarding both technical skills and personal motivation. In our experience, the homogeneously composed groups encourage both skilled and less skilful students to perform at the boundary of their competence, e.g., within their ZPD. One group wrote: “All members were able to contribute to the project, therefore there were no problems with losing the respect for project members because of ‘free riders’ who are in the group but do not contribute.” This, however, was not always the case. One group reported: “One member was almost impossible to contact, which created a lot of tension. Deadlines were not held, and neither chatting nor e-mail helped. In the end the student was excluded from the project.” RUP includes a set of role definitions: project manager, architect, systems analyst, programmer and tester. The roles are described in detail, and are mapped to specific activities. The students sometimes choose to redistribute roles for each iteration. 4.2.7 The role of tutors and supervisors A basic tenet in PBL is that the tutor should act in a supporting, not instructive, manner. However, successful scaffolding requires that advice provided by tutors and supervisors should relate to explicit learning objectives for the module. Adequate scaffolding thus requires that tutors and supervisors responsible for the learning process be fully aware of what is good practice (e.g., for a project process) and what is good product quality. It also requires an understanding of the students’ level of competence at the beginning of the project and during its course, and an understanding of Learning from achievement 121 adequate pedagogical steps to get from the current to the desired level of competence. Providing good advice to students on their project work remains a situated endeavour, however meticulously preplanned the learning process and its scaffolding may be. The provision of appropriate scaffolding to project groups accordingly puts strong demands on supervisors who normally have a limited amount of time allocated for the supervision of each group. Well-structured support material (plans, guidelines, predesigned solutions, etc.) related to the types of scaffolding discussed in the previous section is likely to make it easier for course staff to prepare for and engage in the day-to-day issues surfacing in the supervision of project teams. 5 Conclusion This article reports on an SE project at the Norwegian School of IT, with 1400 students over five years, using the approach of PBL. As the projects are designed to have a certain size and difficulty to provide a real challenge, the risk of failure is considerable. Building on Bruner’s concept of scaffolding, we argue that PBL in an SE course may be successfully facilitated by teachers and supervisors. This allows the students to learn from achievement instead of failures. Supporting PBL with the RUP includes a number of types of scaffolding: • The main project structure is scaffolded by RUP’s phases and iterations. • The microstructure is scaffolded by RUP activities. • Technical development is scaffolded by other taught courses, such as programming. • Product integrity is scaffolded by predefined product modules. • Document quality is scaffolded by predefined document structure and web-based hand-in and assessment. • Group cooperation is scaffolded by homogeneous groups and RUP role definitions. Limitations of the study presented in this article relate to the fact that the empirical data are from only one case, albeit a large and longitudinal one. We suggest that further research address scaffolding mechanisms used in similar and alternative approaches to SE education. Also, the types of scaffolding identified in our work might be used as a basis for the design of similar pedagogical approaches in other educational settings. References Alfonso, M.I. and Botia, A. (2005) ‘An iterative and agile process model for teaching software engineering’, 18th Conference on Software Engineering Education & Training (CSEET’05). Bandura, A. (1994) ‘Self-efficacy’, in V.S. Ramachaudran (Ed.) Encyclopaedia of Human Behaviour, New York: Academic Press, Vol. 4, pp.71–81. Belbin, M. (1993) Team Roles at Work, Butterworth Heinemann. Blumenfeld, P.C., Soloway, E., Marx, R.W., Krajcik, J.S., Guzdial, M. and Palincsar, A. (1991) ‘Motivating project-based learning: sustaining the doing, supporting the learning’, Educational Psychologist, Vol. 26, pp.369–398. 122 B. Bygstad, B.R. Krogstie and T-M. Grønli Brooks, F.P. (1987) ‘No silver bullet – essence and accident in software engineering’, Computer, Vol. 20, No. 4, pp.10–19. Bruner, J. (1960) The Process of Education, Cambridge, MA: MIT Press. Dewey, J. (1997) Democracy and Education – An Introduction to the Philosophy of Education, New York: The Free Press. Gulbahar, Y. and Tinmaz, H. (2006) ‘Implementing project-based learning and E-portfolio assessment in an undergraduate course’, Journal of Research on Technology in Education, Vol. 38, No. 3, pp.309–327. Gutzdial, M. (1994) ‘Software-realized scaffolding to facilitate programming for science learning’, Interactive Learning Environments, Vol. 4, No. 1, pp.1–44. Helle, L., Tynjala, P. and Olkinoura, E. (2006) ‘Project based learning in post-secondary education – theory, practice and rubber sling shots’, Higher Education, Vol. 51, pp.287–314. IBM Corp (2002) ‘Rational unified process’, RUP On-line. Jacobson, I., Booch, G. and Rumbaugh, R. (1999) The Unified Software Development Process, Reading: Addison Wesley. Larman, C. (2001) Applying UML and Patterns: An Introduction to Object-oriented Analysis and Design and the Unified Process, Prentice Hall. Larman, C. (2004) Agile and Iterative Development: A Manager’s Guide, Addison-Wesley. Markham, T. (2003) Project Based Learning Handbook, Buck Institute for Education. Miles, M.B. and Huberman, A.M. (1994) Qualitative Data Analysis, Thousand Oaks: Sage Publications. Morrison, J. (2004) ‘Facilitating collaborative learning within programming projects’, Issues in Information Systems, Vol. 5, No. 1, pp.221–225. Sindre, G., Stålhane, T., Brataas, G. and Conradi, R. (2003) ‘The cross-course software engineering project at the NTNU: 4 years of experience’, 16th International Conference in Software Engineering Education and Training (CSEET’03), Madrid, Spain. Sommerville, I. (2001) Software Engineering, Harlow: Pearson Education. Standish Group (2001) Extreme Chaos. Stone, C.A. (1993) ‘What is missing in the metaphor of scaffolding?’, in M.E. Forman and C. Stone (Eds.) Contexts for Learning: Sociocultural Dynamics in Children’s Development, New York: Oxford University Press, pp.169–183. Suthers, D.D. (2006) ‘Technology affordances for intersubjective meaning making: a research agenda for CSCL’, Computer-supported Collaborative Learning, Vol. 1, pp.315–337. Vygotsky, L.S. (1978) Mind in Society. The Development of Higher Psychological Processes, Cambridge, MA: Harvard University Press. Wood, D., Bruner, J. and Ross, G. (1976) ‘The role of tutoring in problem solving’, Journal of Child Psychology and Psychiatry, Vol. 17, No. 2, pp.89–100.