This paper presents an experience report with a junior-level software engineering course at North Carolina State University. We provide an overview of the course structure and the course project, iTrust, that has been developed by students over 25 semesters. We summarize reflections from faculty, teaching assistants, and students (through course evaluations). From our lessons learned, we present our course improvements as we prepare for the next ten years of software engineering courses. Our main lessons learned are 1) course technologies have a lifespan and require periodic updating to balance student learning and working with a legacy system; 2) teaching assistant longevity and support is critical to course success; and 3) the value of working with a large, legacy system in a semester long course is supported by faculty, teaching assistants, and eventually students.
Soft skills (e.g., the ability to communicate, negotiate, collaborate) are essential for software engineers. However, teaching soft skills in a conventional classroom setting is time-consuming and resource-intensive. In this paper, we present and motivate the idea of adopting active video watching (AVW) for soft skills training in software engineering education. Also, we discuss how AVW can contribute to formal learning (e.g., at universities), but also to professional development (e.g., in software development organizations). Furthermore, we present AVW-Space, a web-based AVW platform. Finally, we report our experience from using AVW in a software engineering project course to teach university students presentation skills as one example of soft skills essential for practicing software engineers.
Software engineering students not only have to learn theoretical concepts but also how to successfully apply them in practice. Hence, projects are an important part of software engineering curricula. As software engineering methods and technologies are only relevant for non-trivial software systems, we report in this paper on a master-level software engineering project course in which a team of students developed a compiler for the Game Boy in a single semester. The students developed different languages and corresponding parsers to a common intermediate language, optimizations on the intermediate language, as well as a code generator for the Game Boy. We particularly present lessons learned by us and the students as well as potential course improvements.
The co-existence of various kinds of devices, protocols, architectures, and programming languages make Internet of Things (IoT) systems complex to develop, even for experienced programmers. Perforce, Software Engineering challenges are even more difficult to address by novice programmers. Previous research focused on identifying the most challenging issues that novice programmers experience when developing IoT systems. The results suggested that the integration of heterogeneous software components is one of the most painful issues, mainly due to the lack of documentation understandable by inexperienced developers, from both conceptual and technical perspectives. In fact, novice programmers devote a significant effort looking for documentation and code samples willing to understand them conceptually, or in the worst case, at least to make them work. Driven by the research question: "How do the lessons learned by IoT novice programmers can be captured, so they become an asset for other novice developers?", in this paper, we introduce Code Recipes. They consist of summarized and well-defined documentation modules, independent from programming languages or run-time environments, by which non-expert programmers can smoothly become familiar with source code, written by other developers that faced similar issues. Through a use case, we show how Code Recipes are a feasible mechanism to support novice IoT programmers in building their IoT systems.
The Liskov Substitution Principle states, among other constraints, that a subtype is not substitutable for its super type if it strengthens its operations' preconditions, or weakens its operations' postconditions. We found that students in two subsequent courses had trouble remembering these rules. Their major stumbling block appeared to be recalling which condition (pre- or post-) could be strengthened and which could be weakened. We developed a simple visual reminder to help: A method is happy if it is substitutable---A smile is wider at the top than at the bottom, suggesting weaker/looser/wider preconditions, and stronger/tighter/narrower post conditions.; A method is sad if it isn't substitutable---a frown is narrower at the top, suggesting stronger/tighter/narrower preconditions, and wider at the bottom, suggesting weaker/looser/wider postconditions. Though the technique is far from perfect, we found that it allowed students to move on to the more interesting design questions around the LSP.
The goal of Software Engineering (SE) education is to teach theory and practice of software sciences, with an ultimate practical goal. Quite surprisingly, although standard SE programs include many hands-on courses, they do not include practical lab courses in software development and maintenance, as common in other engineering disciplines. A capstone project course, that is standard in most SE programs, cannot function as an instructive SE-lab course since it does not enable effective teaching and cannot replace a planned SE-development experiment.
This paper describes an SE-lab course that creates lab conditions, where students are faced with a deliberately challenging, planned SE development and management tasks, and the course staff provides team-based guidance. The paper analyzes the lab ideals, principles and goals, explains how they are realized in the lab content, and presents its evaluation from the students and the instructors' viewpoints.
There is a gap between the abstract concepts taught in the classroom and the skills needed for students to succeed once they join the workplace. The Undergraduate Capstone Open Source Projects (UCOSP) program was developed to narrow this gap by enabling undergraduate computer science students to have an experiential software engineering learning opportunity. Over the past 8 years, 737 students from 30 universities have taken part in this program.
In this paper, we sought to understand student perceptions of how UCOSP complements traditional classwork by providing real-world software engineering exposure. We report on a qualitative analysis of 2,203 quotes collected from 167 students from 18 universities over six academic terms. We analyzed these data using a grounded theory approach based on open coding to gain insight into the key benefits of the program from the students' perspective. We found that students highly value being able to apply their classroom knowledge to real, novel tasks, for real projects with a community of users, while receiving real mentorship from a member of the development team. Further, we found that contributing to real software systems provides greater understanding of software engineering than might otherwise be obtained through more traditional means.
Our goal is that our analysis can help fellow educators add additional experimentalism into their existing programs.
Introducing Open Source Software (OSS) projects into a software-engineering course has many advantages, for instance, allowing students to learn good coding practices from real-world projects, and giving students a glimpse of a real project. However, it is not easy for instructors to induce one or more OSS core teams to lend support for course projects. The alternative is to have students work on "toy features"---features for these projects not specified by OSS core teams, but by teaching staff. However, the project may be unimportant to the OSS project or may disrupt its design, making those code contributions unlikely to be integrated into the OSS code repository. In this paper, we, as both teaching staff and the core team for one OSS project called Expertiza, discuss our experience in supporting 700 students on 313 OSS-based course projects in the past five years. We manually checked these course projects, and summarize 13 common mistakes that frequently occur in students' contributions, such as not following the existing design or messy pull requests. We propose five suggestions to help students reduce the frequency of common mistakes and improve the quality of their OSS pull requests.
Teaching of software engineering using capstone projects has seen a steady growth over the years with overwhelmingly positive reported experiences. Discerning what students consider of value before and after a software project course, is crucial for developing a relevant curriculum. This paper reports on the affective learning outcomes of a Scrum based capstone course with industrial clients. We measured affective learning as changes in the attitudes towards the difficulty and importance of certain aspects present in software development, including technical, teamwork and customer interaction. Data was collected from 14 student teams of 7-9 members in the form of team interviews and individual surveys, with 86 students participating in the interviews and 86 valid survey answers. Our results show that students largely change their attitudes in the desired direction after the course regarding both importance and difficulty, with 57% reporting an increased understanding of the importance of collaboration and communication within the team and 44% reporting less than expected difficulty in learning new technologies/programming languages.
In recent years, Agile development has been adopted in project practices of Software Engineering (SE) courses. However, it is a great challenge to provide timely assessment and feedback to project teams and individual students with a frequency that catches up with iterative, incremental, and cooperative software development with continuous deliveries. Conventional project reviews are mostly dependent upon instructors and teaching assistants in a manual reviewing/mentoring approach, which are simply not scalable.
In this paper, we argue that agile projects warrant a "continuous delivery" of personalized assessment and feedback. To this end, we propose an online-offline combined approach and built a system upon GitLab. An online platform was built by integrating DevOps tool chains so that personalized reports and assessments are delivered automatically to the teams/students, which serve as the very efficient trigger and basis for the close and targeted offline interactions between students and TAs: daily discussion over instant messaging and weekly in person meeting. This system has been in operation since 2014 for an undergraduate SE course, with over 500 students participating in over 130 project teams in total. Our results show that such a continuous assessment/feedback delivery system is very effective in educating Agile projects in SE courses.
It has been 50 years since the term "software engineering" was coined in 1968 at a NATO conference. The field should be relatively mature by now, with most established universities covering core software engineering topics in their Computer Science programs and others offering specialized degrees. However, still many practitioners lament a lack of skills in new software engineering hires. With the growing demand for software engineers from the industry, this apparent gap becomes more and more pronounced. One corporate strategy to address this gap is for the industry to develop supplementary training programs before the hiring process, which could also help companies screen viable candidates. In this paper, we report on our experiences and lessons learned in conducting a summer school program aimed at screening new graduates, introducing them to core skills relevant to the organization and industry, and assessing their attitudes toward mastering those skills before the hiring process begins. Our experience suggests that such initiatives can be mutually beneficial for new hires and companies alike. We support this insight with pre- and post-training data collected from the participants during the first edition of the summer school and a follow-up questionnaire conducted after a year with the participants, 50% of whom were hired by the company shortly after the summer school.
Compile-time errors pose a major learning hurdle for students of introductory programming courses. Compiler error messages, while accurate, are targeted at seasoned programmers, and seem cryptic to beginners. In this work, we address this problem of pedagogically-inspired program repair and report TRACER (Targeted RepAir of Compilation ERrors), a system for performing repairs on compilation errors, aimed at introductory programmers.
TRACER invokes a novel combination of tools from programming language theory and deep learning and offers repairs that not only enable successful compilation, but repairs that are very close to those actually performed by students on similar errors. The ability to offer such targeted corrections, rather than just code that compiles, makes TRACER more relevant in offering real-time feedback to students in lab or tutorial sessions, as compared to existing works that merely offer a certain compilation success rate.
In an evaluation on 4500 erroneous C programs written by students of a freshman year programming course, TRACER recommends a repair exactly matching the one expected by the student for 68% of the cases, and in 79.27% of the cases, produces a compilable repair. On a further set of 6971 programs that require errors to be fixed on multiple lines, TRACER enjoyed a success rate of 44% compared to the 27% success rate offered by the state-of-the-art technique DeepFix.
Development tools have an impact on software engineers' productivity and quality of software construction. We believe that it is crucial to teach future software engineers how to exploit integrated development environment functionality, if we want to encourage the effective application of software development principles and practices. Our research shows that recommender systems can be deployed to improve integrated development environment knowledge of computer science students by automatically suggesting new and useful commands, such as buttons and shortcuts that execute different functions. While previous work focused on optimizing the algorithmic predictive capability of a recommender to identify the commands that the users will eventually use, we have addressed a set of research questions related to the overall acceptance of a complete recommender system in a real-life setting. The evaluation results show that a command recommender system can be well accepted by computer science students. In particular, when students are supported by such a system, they use a considerably larger set of commands available in their development environment. Moreover, the results show that the highest acceptance rate and the usefulness score were achieved by a non-personalized, popularity-based algorithm, while the most novel commands were suggested by a context-aware algorithm.
Recent literature reports a fair amount of initiatives on how to engage younger populations in achieving computational literacy. However, there is considerable less research on how to effectively deliver software development skills in a way that can be accepted and ultimately adopted by this user group. As a way to bridge this gap, we ran an extracurricular project-based workshop, targeting 10-12 years old learners with no prior coding experience, delivered over five days in the computer labs at the University of Chile. In this workshop, participants follow hands-on activities where they acquire the basics of computer programming and develop a small-scale software application using Scratch. These activities showcase that good software engineering practices can be taught to K-6 students, where these students are guided by experienced computer science undergraduate and graduate students. This paper presents a descriptive case study that focuses on assessing how K-6 learners assimilate and use these practices when developing their first computing application in a non-traditional learning experience. In order to do this, we designed and calibrated a rubric to evaluate the software products generated by the workshop participants. Our findings provide further evidence that it is indeed possible to teach initial notions of software engineering to this user group, structuring these constructs in a non-technical language that can be assimilated by novice developers. Furthermore, we did not observe significant differences in this matter according to gender and socio-economic status.
This paper describes our experience using Just-in-Time Teaching (JiTT) in a graduate Software Testing course during two semesters. JiTT is a pedagogical strategy that bridges in-class and out-of-class components through preparatory web-based assignments, known as warm-ups. Our JiTT design was as follows. The preparatory out-of-class component consisted of a reading test, which required students to read a chapter from the textbook and then answer a web-based test available in our virtual platform. Reading tests were due the day before class in order to give the teacher enough time to read over the student's responses and adjust the next lesson accordingly. The in-class component was organized around student common misconceptions or difficulties, extracted from the reading tests submitted by the students. Discussions and cooperative learning activities were among the teaching strategies used in class. Our approach was assessed from the students' and teacher's perspective. The students' perspective was obtained from a survey. The teacher's perspective consisted in an assessment of strengths and limitations. Results from our evaluation show that a vast majority of students believe their learning improves when they prepare for class by reading the material in advance. They also think that reading tests are an effective way of verifying that students did the assigned reading. Most of them also consider that JiTT is an appropriate teaching strategy for the course. From the teacher's perspective, a major strength found was that students were more engaged in class, asking interesting questions that enriched class discussion. Also, the use of open-ended (essay-type) questions in reading tests has the additional benefit of helping them become better writers (organize their ideas better and clarify their thinking through writing).
It is now common for software engineering programs to include some project management education, typically in the final year of the undergraduate program, or at the postgraduate level. Such courses are challenging for several reasons: faculty are unfamiliar with management education and literature; the software project management literature is dominated by nonempirical, atheoretical, unscientific practitioner recommendations; common software engineering pedagogical approaches are inappropriate for teaching management; and many students seem unwilling or unable to take the course seriously (that is, by attending all classes and completing all assigned readings, activities and projects). This paper describes a postgraduate management course in software engineering, which was iteratively refined over seven years to address all of these problems. Its key features include: 1) scholarly, evidence-based readings; 2) quizzes on readings at the beginning of every class; 3) Brief, slide-free lectures; 4) copious in-class activities formalized into a gradeable workbook; 5) an ambitious, multistage project combining novel research, collaborative data collection and literature reviewing, peer review workshops and individual deliverables. The course embodies both research-led teaching and substantial, novel class-based research.
A critical aspect of software process education in general and software process improvement (SPI) education in particular is to give students the chance to experience processes and issues associated with process at first hand. This is, however, often difficult in an educational setting since providing a meaningful project in which to apply a process can take away time and focus from the intended learning objectives. Instead, miniatures and simulations can be used to create an environment in which students can interact with processes directly without taking up large parts of the curriculum.
In this paper, we report on our experience of using Lego Scrum simulations in an SPI course at the Bachelor level. The simulations are used both to introduce a baseline for the students to let them experience process issues directly, create an improvement plan that addresses observed issues, and to apply and evaluate the plan in a second simulation. This allows students to engage with SPI methods practically, instead of purely theoretically, and allows the teacher to refer to the shared experience throughout the course.
The collected data shows that the approach is suitable, but that students struggle with the demand of putting an improvement plan into practice. We show which issues commonly occur in the simulations and thus allow teachers who adopt the practice to scaffold it and react accordingly, in particular to empower the students to take on responsibility for the improvement of the process.
Modeling in Software Engineering is a complex task which includes interaction and discussion. Often multiple iterations are needed to end up with a satisfying design to handle given problems like complexity or change. This behavior can also be seen in education in software engineering, where learners tend to iterate over their models after having multiple discussions with their instructors or peers about possible solutions. This is an important part of the learning process, however, it is increasingly harder to implement for large scale on campus courses due to high student to lecturer ratios. One of the biggest problems is that lecturers are not able to allocate their time during class to support all students equally. This issue leads to new teaching methodologies and automated or semi-automated tools to support in-class interaction of students. However, these tools are lacking an automated mapping between questions asked and the teaching context provided. This context has to be inserted manually or is implicitly available during the lecture, however is lost after the lecture is over. In this paper we describe the adaption of a lecture-style instruction and the introduction of a context-aware Q&A teaching framework to increase student interaction by parallelizing it with content delivery. We achieve this while also lowering barriers for students to participate, even in multi-classroom setups. The stated approach also allows the creation of a knowledge repository which persists student interaction including its teaching context. This repository can be used by students to prepare for upcoming exams as well as by instructors to optimize their teaching content. Using our approach, we are able to show that there is an increase in student participation, leading to increased student examination performance for active students.
This paper contributes to the growing literature on the gender gap in computer science education by focusing on an exploratory case study conducted at the IT University of Copenhagen (ITU), Denmark. The specific objective of this study was to draw on existing research in order to empirically investigate the main socio-cultural barriers to female participation in the bachelor of Software Development at ITU, and to generate insights that would inform concrete and effective interventions. This investigation takes the form of an exploratory case study, providing insights into influential factors such as students' perceptions, attitudes and behavior towards software development education and gender differences in pre-university coding skills.
Empirical evidence has been collected through semi-structured interviews with 38 students (undergraduate and high school) and surveys with 395 students (undergraduate and high school). Research findings from the study have subsequently informed the design of local interventions that have led to the recruitment of double the percentage of women in the bachelor of Software Development at ITU in one year, from 11% in 2016 to 22% 2017. The study also describes and discusses such interventions.
Sustainability has become an important concern across many disciplines, and software systems play an increasingly central role in addressing it. However, teaching students from software engineering and related disciplines to effectively act in this space requires interdisciplinary courses that combines the concept of sustainability with software engineering practice and principles. Yet, presently little guidance exist on which subjects and materials to cover in such courses and how, combined with a lack of reusable learning objects. This paper describes a summer school course on Software Engineering for Sustainability (SE4S). We provide a blueprint for this course, in the hope that it can help the community develop a shared approach and methods to teaching SE4S. Practical lessons learned from delivery of this course are also reported here, and could help iterate over the course materials, structure, and guidance for future improvements. The course blueprint, availability of used materials and report of the study results make this course viable for replication and further improvement.
Teaching Software Engineering on an undergraduate programme is challenging, particularly when dealing with large numbers of students. On one hand, a strong understanding of software and good programming skills are prerequisites. On the other hand, the scale of the projects developed as part of undergraduate programmes do not always make the need for engineering obvious. Encouraging teamwork when students have little professional experience also adds to the level of complexity when delivering material. In this paper, we present a study on the redesign of a second year undergraduate course on Software Engineering for a large cohort.