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.