Teaching software engineering: an active learning

experience
Sergio Villagra Guido De Benedetti Tomás Bruno
Computing Department Computing Department Computing Department
School of Engineering, University of School of Engineering, University of School of Engineering, University of
Buenos Aires Buenos Aires Buenos Aires
Buenos Aires, Argentina Buenos Aires, Argentina Buenos Aires, Argentina
guvillagr@fi.uba.ar gdebenedetti@fi.uba.ar tomas.bruno.o@gmail.com

Leonardo Fernández Nicolás Outeda

Computing Department Computing Department
School of Engineering, University of School of Engineering, University of
Buenos Aires Buenos Aires
Buenos Aires, Argentina Buenos Aires, Argentina
leofernandez777@gmail.com nmouteda@gmail.com

Abstract—Teaching has changed; students, too. Software
engineering is always evolving. In this paper, the authors present
their experience teaching an introductory course to software
engineering applying active learning, flipped classroom,
gamification, and WAC (Writing Across the Curriculum) at the
University of Buenos Aires' School of Engineering.
Keywords— Software engineering, education, active learning,
flipped classroom, gamification, writing across the curriculum
I. INTRODUCTION
Since 1979, the University of Buenos Aires' School of
Engineering offers a four-and-a-half-year program in systems
analysis which, despite its name, is oriented to software
engineering (SE) [1].
The curriculum, which was updated in 1986, included
courses on calculus, algebra, computer design fundamentals,
programming, requirements analysis, software design,
database design, operations research, project management,
economics, and software engineering management.
In early 2008 it was clear that this curriculum, which
worked pretty well for several years, needed a change. Faculty
and graduates recognized that contents had to be updated, and
also the strategy in which topics were presented to students.
Like other similar programs, SE knowledge areas (KA) [2]
were presented in a sequential, siloed way: first, several
programming courses; second, a requirements analysis
course; later, design and software management courses. This
approach created at least two problems: first, students didn't
get a general idea of how different SE disciplines and practices
work together until late in the program; second, coordination
of contents between instructor teams are complex and,
usually, topics inevitably overlap.
The Curriculum Advisory Committee, integrated by
representatives of faculty, graduates, and students, whose
main responsibility is keeping the program updated, started
the design of a new curriculum, which was implemented in
2014, after several years of work and talks between parties to
reach a consensus.
Besides refreshing content and creating new mandatory
and elective courses, the new program presents SE KA more
iteratively and incrementally. For instance, Software Testing
and Software Configuration Management KA are now
formally presented in the first programming courses. In the old
curriculum, those topics were covered in advanced, more
focused SE courses.
The old Requirements Engineering and Software Design
courses were replaced by two new courses -namely Methods
and Models in Software Engineering I and II, respectively- in
which all SE KA are covered, but with varying intensity. In
the first one, the focus is on discovering, specifying, and
modeling requirements, prototyping, and user experience
design, software design, and coding. In the second course, the
focus is less on requirements and more on architecture design,
testing, deployment, software evolution, and process
discipline.
In late 2014, we were appointed by the Computing
Department as instructors of Methods and Models in Software
Engineering I. We delivered it for the first time in the first
semester of 2015. Previously, we had been teaching a software
economics course for almost ten years, applying successfully
an approach based on a blend of strategies: active learning,
flipped classroom, writing across the curriculum, and project-
based teamwork. We decided to apply the same approach to
the new course. At the time of writing this article, we have
taught the course nine times and more than 270 students have
attended.
In this paper, we describe our experience teaching the
course with this approach, the results we obtained, and our
reflections about it.
II. RELATED WORKS
Van Vliet [3] identifies several traps to avoid in the design
and delivery of an introductory course to SE. Schilling and
Sebern [4] describe an experience applying active learning in
a SE course. Páez [5] describes the adoption of a flipped-
classroom approach in an introductory course to SE. Ivanova,
Kozov and Zlatarov [6] describe an experience applying
gamification in several SE related courses.
III. TEACHING APPROACH
As mentioned before, our course covers several SE KA
related topics, including a general introduction to systems
theory and software engineering, requirements engineering,

978-1-7281-5957-7 / 20 / $ 31.00 © 2020 IEEE

user experience and software architecture (see Fig.1). It also
introduces students to more complex topics, like peopleware,
software methods, software processes and software
engineering management, which are reviewed in detail in the
next course. Around 50% of the course time is allocated to
requirements, 20% percent to software architecture and
design, and the remaining 30% to the other topics.
Fig. 1. Course Topics
Besides presenting some classic concepts and introducing
the works of very well-known authors, we emphasize the idea
that software is best developed incrementally and iteratively,
using agile methods and practices. Students have the
opportunity to develop a software product applying this
approach, under our management supervision.
The course lasts for sixteen weeks. Classes take place
twice a week and last for about three hours. There are no
lectures and the activities in the classroom are generally
practice-oriented: workshops, modeling sessions, interviews,
team meetings, peer reviews, and the like. Besides, students
are expected to spend about six hours a week on activities
outside the classroom, like reading, solving quizzes and
working in teams.
As noted by Páez [5], keeping students engaged is a
challenge in these modern days. Paying attention is difficult
when smartphones are at hand. A classic thirty- or forty-
minutes long slide presentation is out of the discussion. As we
mentioned earlier, we have found that a blend of different
techniques and strategies can make a difference. We apply a
teaching approach based on what we call four pillars: active
learning, flipped classroom, writing across the curriculum and
project teamwork. In the following sections, we will describe
it in detail and how we put it into practice.
A. Active Learning
Active learning [7] is a general approach, actually
transversal to all the teaching activities we perform. The idea
behind this is to change the usual behavior of the students in
the classroom, in which lecturers speak and students listen
passively, taking notes. Active learning wants students to
become active subjects of the teaching/learning process
employing different tools and techniques.
We put this approach into practice by applying several
strategies. First of all, there are no lectures and, also, no tests.
As we describe in the next section, our lectures are video-
recorded and kept as short as possible, which leaves us time
for more engaging, hands-on activities in the classroom, like
debates about well-known cases in the industry (for example,
the Ariane V software failure [8]), games (like the Spec
Writing Game [9] or our adaptation of the Paper Tower
Competition [10]), domain modeling sessions, user story and
prototyping workshops, product demos and competitions
using online tools like Kahoot! [11]. And instead of the
standard mid-term and final written exams, we apply a
nonconventional evaluation approach in which students are
assessed according to: a) their participation in project-based
teamwork; b) how they individually solve quizzes, perform
modeling and specification activities, and write small essays;
c) how many points they get in the gamification scheme we
propose, in which they can get points for participation in
hands-on activities in the classroom, on-time delivery of
homework, etc; and, finally d) assessment by the instructors
of several items, like teamwork, participation in class,
academic integrity, contribution to classroom climate, etc.
This approach, in addition to giving us more frequent
feedback and a better perspective of performance than a
written exam, also allows us to keep students engaged
throughout the whole semester.
B. Flipped Classroom
As mentioned in the previous section, there are no classical
lectures in our course. This is another of our pillars, called
flipped classroom [12], a learning approach in which
classroom activities are organized around practical cases and
group discussions instead of lectures, which are video
recorded to be watched by the students at home, before going
to class. Currently, we have a total of 14 recorded lectures, for
a total of about six hours. To engage students, videos are kept
short (not always successfully) and edited with Edpuzzle [13],
a software tool that allows us to include interactive quizzes in
selected sections of the lecture and also track if they really
watch it.
C. Writing Across the Curriculum
Besides video-recorded lectures and hands-on activities,
students have to acquire knowledge through reading. And
there is a lot to read in an introductory course like this one.
Writing Across the Curriculum, or WAC, [14] is a
teaching movement that wants to encourage students to write
to understand, no matter the educational level or professional
discipline. Writing an essay or a small piece of text
summarizing a book or an article has a profound influence on
the cognitive process. Students don't just read what they are
asked for: they have to look for the main ideas and identify the
potential connections with other authors; in summary, they
have to truly understand.
By applying this approach, we pursue two goals: first,
allow students to communicate in writing, a critical skill for
every professional which we feel is not very well covered in
the curriculum; and second, to encourage students to read
some of the software engineering classics they should know.
To complete their written assignments, which include short
essays and quizzes, students have to read papers by Frederick
Brooks [15], Barry Boehm [16], Martin Fowler [17], David
Parnas [18] and excerpts of books by Craig Larman [19], Karl
Weigers [20] and Mike Cohn [21].
D. Project-based teamwork
Finally, our fourth pillar is project-based teamwork, which
in our case involves the conceptualization, design and
development of a small software application with minimum
features to be usable (MVP, or minimum viable product). The
goal of this endeavor is to give students a full lifecycle
software development experience in which they can apply in
practice the methods and techniques described in the lectures
and in the readings. To be as close to real-life as possible, there
is no description of the problem to solve; instead, there is a
simple document describing the general situation of the
fictitious organization requiring the product. Requirements
have to be progressively discovered by interviewing potential
users, played by some of the instructors. There are a script and
a baseline definition of requirements for the internal
consumption of the teaching staff. Students apply an agile
software development process, loosely based on Scrum, with
a previous product discovery stage inspired by the Design
Thinking approach, like the one proposed by Hehn,
Uebernickel, and Méndez Fernández [22].
To run the project in the most orderly way possible,
students are organized in squads and tribes, in a way very
loosely inspired by how Spotify works [23]. Each squad,
composed of between 3 to 5 members, is in charge of one
subsystem or module of the product; three squads form a tribe,
which is in charge of the entire product. Squads work together
as a tribe to discover the requirements, establish the product
vision, and create an initial product backlog. Then, each squad
design, develop, test and integrate its own subsystem.
As this course is more focused on technical knowledge
areas, the management function is covered by the teaching
staff. One of the instructors covers the program manager role,
who guides students and organizes project activities, allowing
students to concentrate more on technical issues and not on
management-related aspects. There is also a product owner
role, covered by another instructor, whose mission is to help
teams establish the vision and the product backlog.
With the help of the product owner and the program
manager, students organize the work using a release plan, a
product backlog and an iteration backlog. Under their
supervision, teams conduct user interviews, impact mapping
sessions, requirements workshops, team meetings,
prototyping sessions, user story mapping sessions and product
demos. They also organize and plan design, programming,
testing and integration activities. After each iteration, they run
a retrospective, identifying lessons learned and possible
improvements to the entire development process.
An important issue for students is the decision of which
languages, tools and frameworks should be used to develop
the product. We don't have any preferences, but we try to
guide them to make the best choice possible according to their
previous knowledge and the complexity of the task. In recent
years, they have mostly chosen React JS to develop the
frontend; Spring Boot to develop the microservice-based
backend; Cardboard for user story mapping; Balsamiq for user
interface prototyping; Github for code management;
Cucumber for automated testing; Jira for user stories, product
backlog, and task management; and Heroku for deploying
software in the Cloud.
Recently, we have developed a simple web application as
an example of how to use some of these tools and how to apply
in practice the software architecture concepts discussed in the
course. Students can take this application as the basis for
developing their own software, cloning the repository.
E. A controlled, near real-life experience
Students face various challenges when coming to our
course. Their previous experience is limited to developing
small programs, in small groups, and with clear, written
requirements. Suddenly, they have to develop a software
product in which several groups are involved, requirements
have to be discovered and new methods and techniques have
to be applied.
As Van Vliet [3] points out, this could be too much for
students if it is not properly managed. That's the reason why
we have instructors covering more senior roles. The program
manager not only guides students but also gets actively
involved in the planning and the direction of the program. The
product owner, on the other hand, guides teams in the
requirements discovery and analysis activities, unifying the
divergent views and opinions of the different users involved,
helping them to create the product backlog and keep it updated
throughout the entire development lifecycle. In this way,
students can have almost real-life experience in a controlled
and managed environment.
F. Continuous Improvement
We have delivered this course nine times since 2015 and
more than 270 students have taken it by the time of writing.
We always look for improvements and as a result of students'
feedback and lessons learned, we have progressively made
changes to our approach. New readings, lectures and practical
activities have been included and others have been replaced.
New productivity tools have been introduced. We have tried
different strategies and tactics for the development project.
Being part-time instructors and with several decades of
collective experience in the software industry, we also make a
big effort to show students how things work in real-life
projects and organizations.
We have also made several changes to how we manage
administrative work. Thanks to tools like Google Classroom,
which we use to assign and grade students activities, Google
Forms, which we use to create quizzes, Google Drive, in
which we publish the course material, and Slack, which we
use to communicate with our students instead of email, our
lives are a little easier.
IV. RESULTS
At the end of each semester, we survey students to get
quantitative results and run a retrospective to get more
qualitative feedback. In the last five years, 230 students have
participated. Results show a high degree of acceptance of the
course, with an average rating of 4.01 on a scale from 1 (Bad)
to 5 (Excellent), and of the teaching approach, which has an
average of 4.17 on the same scale. A total of 78% of
respondents found the course excellent or very good (Fig.2)
and 80% rated the teaching approach as excellent or very good
(Fig.3).

Fig. 2. Students' evaluation of the course
Fig. 3. Students' evaluation of the teaching approach
Additionally, we also ask students to rate, on the same 1 to
5 scale, other dimensions of the course, like recorded lectures,
individual exercises and quizzes, project team-work, and
workload. The results look also good (Fig. 4).
Fig. 4. Students' evaluation of other aspects of the course
Workload has an average of 3.71, with a total of 13% of
respondents indicating it was excessive or fairly excessive, for
24% it was good, and 63% thought it was adequate or more
than adequate. Project-based teamwork was rated 3.72, with
only 1% of students declaring that it didn't help the course
objectives. Quizzes, essays and other individual homework
were rated 4.03, with only one student declaring that they were
really bad and 16 students (7%) stating that they were not very
appropriate.
Not surprisingly, we found a high correlation between the
rating that students give to the course and their satisfaction
with the teaching approach, as Table I shows.
A similar trend was identified when we compared other
dimensions. Those who evaluated the course as very good or
excellent, also found very good or excellent the instructors'
knowledge and attitude (77%), the video-recorded lectures
(69%), homework (65%), and project-based teamwork (55%).
Retrospectives provide some anecdotal evidence about
additional aspects of the course, which we always consider
while identifying improvement opportunities. The comments
have always been very positive, praising the general approach,
contents, and instructors' commitment and attitude towards
students. There is also a place for some criticism. For instance,
one of our first students judged that the activities performed in
the classroom were recreational. Another felt too much
pressure from instructors to keep homework up to date.
Occasionally, a few students (about 7%) have complained
about specific situations, like delays in instructors' feedback,
some boring activities, an unbalanced workload, and finishing
some classes later than expected. In the first semester of 2020,
one of the two tribes suggested having some texts in Spanish
and producing even shorter lecture videos.
TABLE I. COURSE EVALUATION VERSUS TEACHING APPROACH
Course Evaluation
Bad Regular Good Very Good Excellent
Bad 1% 2% 0% 0% 0%
Teaching Approach
Regular 1% 1% 1% 1% 0%
Good 0% 0% 3% 7% 2%
Very
0% 0% 5% 19% 7%
Good
Excellent 0% 0% 4% 19% 25%
We also have some evidence of problems in the social
dimension. In almost all the semesters, at least one of the
teams delivers low-quality artifacts and shows poor
performance. We have found that the social tension inside the
team and the lack of commitment of members are the major
reasons. We also suppose that the 3.72 score in the project
dimension could be the result of these internal tensions, at
least partially. Of course, when we detect any team with this
type of issue, we immediately help to get the project back on
track as soon as possible.
A. Continuous evaluation
Ongoing assessment of students is a complex task if you
are not well organized or if the group is too big. As mentioned
before, it is very important to have in place the right set of
productivity tools to optimize instructor activities like
communicating with students, creating quizzes, and assigning
and grading homework. Also, to keep students engaged and to
give feedback on a one-on-one basis, we have found that one
instructor per every five students is an excellent ratio. More
students per instructor made feedback less frequent and delay
the learning loop.
B. COVID-19 Pandemic
A few weeks before the beginning of the first semester of
2020, the OMS declared the COVID-19 pandemic. University
authorities suspended face-to-face classes and a contingency
plan was quickly activated to prepare faculty, staff and
technical infrastructure to be ready to deliver the courses
online. Finally, the semester started in late April, four weeks
later than originally planned.
Fortunately, this situation wasn't a big challenge for us due
to how our course is organized. All the material and videos are
published on the web, and our administrative platform is
online too. It was just a matter of moving to Zoom the
activities we usually perform in the classroom. The transition
felt natural for us and the students; moreover, we think that
some of the activities notably improved because of being now
online. Sharing models, user stories, prototypes, code and
demos on the web was much better than trying to do it in the
classroom, where a reliable wifi connection is not always
available and the projection of the laptop screen is usually on
a small surface, difficult to see. Students always looked
engaged and paid attention.
V. CONCLUSIONS AND FUTURE WORKS
We are very satisfied with the results we have consistently
got in all these years. Of course, there is always room for
improvement. As in software development, there are new
iterations in which you could try things differently. We still
have to improve some of the videos of the classes, decide if
we need to put less focus on some topics and more on others,
complete the application example with more features and
additional artifacts, evolve some of the exercises and decide if
we should provide students with a more prescriptive
development, testing and management toolset.
The COVID-19 pandemic has had a huge impact on
academic activities around the world. Fortunately, our course
was ready to be delivered totally or partially on the web, and
we did it successfully. Moreover, our initial evaluation is that
some team activities, like modeling, prototyping, artifacts
reviews, etc. have gone much better online than in the
classroom. While it is difficult to determine, by the time of
writing, which is going to happen to education after the
COVID-19 pandemic, we are sure that we will try to
influence, as much as we can, that our course be delivered as
a mix of online and onsite activities, limiting the physical
presence of students and instructors only when face to face is
irreplaceable. This is another change that we would like to
drive.
Besides these ideas, we realize that we are helping to close
the gap between academia and industry, and we would like to
keep that trend. We perfectly understand that these two worlds
are not the same and universities are not the place where future
workers are instructed in the specific tools and methodologies
that organizations require. Anyway, some balance is needed.
We feel that today we are providing students with knowledge
and abilities that they can readily apply to real-life situations,
under the supervision of more senior professionals. The
situation twenty years ago was completely different. Now,
after finishing our course, the students have some near real-
life experience in requirements discovery and analysis
methods, user stories, software architecture design, test
automation and iterative development. They also have used
some of the most popular and public-domain development,
testing and deployment toolchains. All these items, along with
a solid theoretical foundation, contribute to preparing them to
be ready to work in a fast-paced, knowledge-intensive
industry, so important for a developing country like the one in
which we live [24]. That is our ongoing commitment: helping
to educate new generations of software engineering
professionals.
ACKNOWLEDGMENTS
We would like to thank Nicolás Páez, instructor of
Methods and Models in Software Engineering II, who insisted
we write down our experience teaching this course.
REFERENCES
[1] Daffra, Ítalo. Historia de la Industria Informática Argentina. C√°mara
de Empresas de Software y Servicios Informáticos-CESSI, 2014.
[2] Bourque, Pierre, and Richard E. Fairley. Guide to the software
engineering body of knowledge (SWEBOK (R)): Version 3.0. IEEE
Computer Society Press, 2014.
[3] Van Vliet, H. "Reflections on software engineering education." IEEE
Software 23.3 (2006): 55-61.
[4] Schilling Jr, Walter W., and Mark J. Sebern. "Teaching software
engineering: An active learning approach." The ASEE Computers in
Education (CoED) Journal 4.1 (2013): 13.
[5] Paez, Nicolás Martín. "A flipped classroom experience teaching
software engineering." 2017 IEEE/ACM 1st International Workshop
on Software Engineering Curricula for Millennials (SECM). IEEE,
2017.
[6] Ivanova, Galina, Vasil Kozov, and P. Zlatarov. "Gamification in
Software Engineering Education." 2019 42nd International
Convention on Information and Communication Technology,
Electronics and Microelectronics (MIPRO). IEEE, 2019.
[7] Bonwell, Charles C., and James A. Eison. Active Learning: Creating
Excitement in the Classroom. 1991 ASHE-ERIC Higher Education
Reports. ERIC Clearinghouse on Higher Education, The George
Washington University, One Dupont Circle, Suite 630, Washington,
DC 20036-1183, 1991.
[8] Dowson, Mark. "The Ariane 5 software failure." ACM SIGSOFT
Software Engineering Notes 22.2 (1997): 84.
[9] Bozzuto, B., 2010. Spec Writing Game - Solutionsiq. [online]
SolutionsIQ. Available at:
<https://web.archive.org/web/20170705152317/http://www.solutionsi
q.com/spec-writing-game/> [Accessed 4 September 2020].
[10] Wangenheim, C., 2009. Activities For Teaching Project Management.
[online] Inf.ufsc.br. Available at:
<http://www.inf.ufsc.br/~c.wangenheim/subpaginas/old/ProjectMana
gementTeaching.html> [Accessed 4 September 2020].
[11] Kahoot.com. 2020. [online] Available at: <https://kahoot.com/>
[Accessed 4 September 2020].
[12] Tucker, Bill. "The flipped classroom." Education next 12.1 (2012):
82-83.
[13] Edpuzzle. 2020. [online] Available at <https://edpuzzle.com/>
[Accessed 31 August 2020]
[14] Carlino, Paula. Escribir, leer, y aprender en la universidad. Una
introducción a la alfabetización académica. Fondo de cultura
económica, 2005.
[15] Brooks Jr, Frederick P. "No Silver Bullet: Essence and Accidents of
Software Engineering. Computer." IEEE Computer Society,
Washington, DC 10 (1987).
[16] Boehm, Barry W. "A spiral model of software development and
enhancement." Computer 21.5 (1988): 61-72.
[17] Fowler, M., 2005. The New Methodology. [online] martinfowler.com.
Available at:
<https://martinfowler.com/articles/newMethodology.html> [Accessed
4 September 2020].
[18] Parnas, David L. "On the criteria to be used in decomposing systems
into modules." Pioneers and Their Contributions to Software
Engineering. Springer, Berlin, Heidelberg, 1972. 479-498.
[19] Larman, Craig. Applying UML and patterns: an introduction to
object-oriented analysis and design and iterative development.
Pearson Education India, 2012.
[20] Weigers, Karl E. "Software requirements, 2nd." Redmond, Wash.:
Microsoft Press, xii (2003).
[21] Cohn, Mike. User stories applied: For agile software development.
Addison-Wesley Professional, 2004.
[22] Hehn, Jennifer, Falk Uebernickel, and Daniel Mendez Fernandez.
"DT4RE: design thinking for requirements engineering: a tutorial on
human-centered and structured requirements elicitation." 2018 IEEE
26th International Requirements Engineering Conference (RE). IEEE,
2018.
[23] Barska, Emilia. 2017. Spotify Engineering Model with Squads,
Tribes, Chapters and Guilds. [online] <https://www.growly.io/spotify-
engineering-model-with-squads-tribes-chapters-and-guilds/>
[Accessed 3 September 2020].
[24] Ammachchi, N., 2013. Argentina's software industry is on the rise.
[online] Available at: <https://nearshoreamericas.com/argentinas-
software-industry-is-on-the-rise/> [Accessed 4 September 2020].
.