Training Software Engineers Using Open-Source Software: The Students' Perspective

Too often, computer science programs offer a software engineering course that emphasizes concepts, principles, and practical techniques, but fails to engage students in real-world software experiences. The authors have developed an approach to teaching undergraduate software engineering courses that integrates client-oriented project development and open source development practice. They call this approach the Client-Oriented Open Source Software (CO-FOSS) model. The advantages of this approach are that students are involved directly with a client, nonprofits gain a useful software application, and the project is available as open source for other students or organizations to extend and adapt. This chapter describes the motivation, elaborates the approach, and presents the results in substantial detail. The process is agile and the development framework is transferrable to other one-semester software engineering courses in a wide range of institutions.

We developed a software engineering course that emphasizes code maintenance and evolution by having students reverse engineer and modify open-source projects. To evaluate whether this course had the desired effects on student learning, we analyze pre- and post-course survey data using qualitative methods. This analysis, in combination with other data, suggests that the students gained an appreciation and understanding of software maintenance, documentation, and tool use.

Over time much has been written on how to organize a course on software engineering, with arguments flowing for and against additional complexity. It is highly believe that SWE is an umbrella course in computing and most dangerously in any course proclaimed to be specialist in generating Software Engineers. Unfortunately, this may still not be widely recognized, both in the industry and in academia. The modern course on SWE requires that the student is familiar not just with many aspects of computing such as programming languages but rather with many other aspects including networking, Internet technologies, programming languages, databases, Human Computer Interaction (HCI), computer graphics, and project management. Depending on the year of academic study these expectations could be unrealistic, especially if that is a 2nd year course. Based on the above view, it is essential to investigate what are the necessary attributes of an ideal Software Engineering at the undergraduate level and how much it is covering of the requirements imposed by the business and industry market. This paper will investigate how appropriate are Software Engineering courses at the undergraduate level in terms of the areas of concentration, delivery approach, and the real life practical training received by the target group of students. It will deeply investigate the overall intended learning objectives and how they are related to the choice of modules offered. On the other hand, a number of business institutions will be surveyed for achieving an overview of how effective graduates of Software engineering courses are within these selected institutions and most importantly what are the challenges they encounter in professional life given their level of university education i.e. how helpful their undergraduate education has been helpful to their development as specialists.

As software becomes more ubiquitous and complex, the cost of software bugs continues to grow at a staggering rate. To remedy this situation, there needs to be major improvement in the knowledge and application of software validation techniques. Although there are several software validation techniques, software testing continues to be one of the most widely used in industry. The high demand for software engineers in the next decade has resulted in more software engineering (SE) courses being offered in academic institutions. However, due to the number of topics to be covered in SE courses, little or no attention is given to software testing, resulting in students entering industry with little or no testing experience. We propose a minimally disruptive approach of integrating software testing into SE courses by providing students access to a collaborative learning environment containing learning materials on testing techniques and testing tools. In this article, we describe the learning environment and the studies conducted to measure the benefits accrued by students using the learning environment in the SE courses.

As a practice-oriented discipline, Software Engineering (SE) is most effectively taught by using a variety of hands-on experiences. Team-based projects where students can practice their technical and soft skills are a key feature of many software engineering courses aimed to prepare students for the realities of industrial software development. Current research indicates that projects offered in SE courses should have a close connection to the real world, be large scale and complex. On the one hand, students should be able to relate to the requirements and understand them without spending much time acquiring domain knowledge. On the other hand, students should be exposed to changing and evolving requirements, which is one of the main challenges of real-world software projects. Software projects should be large enough and have enough features to engage all members of the student team while enabling them to practice some degree of specialization and experience the advantages and challenges of teamwork. Software projects should be rich enough to allow students practice all previously acquired SE concepts, bring together knowledge from other specialized CS disciplines, and apply a number of modern tools and technologies. One of the most effective ways to learn SE is to expose students to an environment that resembles an industrial setting as much as possible. As a part of an academic program, SE courses can achieve this objective by offering students a balanced combination of three components: teamwork involving up-to-date technology grounded in a solid theoretical foundation . Instructors in SE courses are uniquely positioned to help maintain this balance by simultaneously playing four roles described below. As a customer who contracts a student team to implement a particular project, the instructor may provide a verbal or written description of the project. It is the students? responsibility to conduct the requirements elicitation interviews and to prepare formal requirements specification for subsequent validation with the customer and possible adjustment. The instructor may act as a customer during the acceptance testing throughout the project to make sure that the team is on the right track at every iteration of the project. The instructor acting as a customer can also act as a proxy if the project has been offered by an industrial partner, or some other department or organization on campus. As an architect initially specifying the overall structure of the solution, the instructor can help students choose the right software architecture. This is a very important choice that has to be made early because it impacts the overall flow of the project. Later architectural changes can be extremely costly and can significantly jeopardize meeting the deadlines. Most likely, students do not have experience in making such architectural decisions and, therefore, it is crucial for the instructor to provide some guidance in this important process. As a team manager concerned with risk management, the instructor needs to pay attention that the team efforts are not jeopardized due to a potential lack of students? soft skills and that these skills are built up as the project progresses. Although it is the students? responsibility to create all artifacts emerging from the project, the instructor can help the team adhere to the schedule by providing feedback based on the inspection of all produced artifacts. In this respect, the roles of the team manager and the customer may somewhat overlap because the same person will be providing feedback to the team from the technical point of view (artifact inspection), as well as from the customer point of view (verification of product implementation at each iteration). In addition to the traditional role of giving lectures, the instructor needs to be a mentor offering guidance to each team and individual students addressing their specific needs and answering questions unique to their projects and the responsibilities in the context of the project. Furthermore, the instructor is uniquely positioned to advise individual students on how to resolve potential conflicts within a team. Such an advice given at the right time could make a difference between completing the project on time and allowing interpersonal tensions completely ruin any chance of collaboration between the team members.

In software engineering education, large projects are widely recognized as a useful way of exposing students to the real-world difficulties of team software development. But large projects are difficult to put into practice. First, educators rarely have additional time to manage software projects. Second, classrooms have inherent limitations that threaten the realism of large projects. Third, quantitative evaluation of individuals who work in groups is notoriously difficult. As a result, many software engineering courses compromise the project experience by reducing the team sizes, project scope, and risk. In this paper, we present an approach to teaching a one-semester software engineering course in which 20 to 30 students work together to construct a moderately sized (15 KLOC) software system. The approach combines carefully coordinated lectures and homeworks, a hierarchical project management structure, modern communication technologies, and a web-based project tracking and individual assessment system. Our approach provides a more realistic project experience for the students, without incurring significant additional overhead for the instructor. We present our experiences using the approach the last 2 years for the software engineering course at The College of William and Mary. Although the approach has some weaknesses, we believe that they are strongly outweighed by the pedagogical benefits.

The evaluation of an advanced software engineering (SE) course is a challenging task that should be addressed as part of the course design. In this paper, we describe an implementation of the reflective practitioner perspective as part of an advanced SE course and introduce its use for feedback purposes. Reflective feedback goes beyond merely using feedback questionnaires. Furthermore, we show, using both qualitative and quantitative empirical data, that the course on which the perspective was applied meets its objectives and fosters students' awareness to the multidimensional nature of SE.

This research to practice full paper investigates software engineering students' perceptions of their contact with open source projects as a real-world experience. Working with open source projects (OSPs) has been shown as an interesting option in software engineering courses to bringing students closer to more realistic environments. However, when instructors use this approach, it is not clear whether students perceive the OSP as a real industrial software project, or whether they perceive the tasks they perform over OSPs as typical or close to industrial software project activities. The goal of this work was to identify students' perceptions of their interaction with an open source project as a real world experience. To do so, we performed three mixed-methods case studies with three different undergraduate classes. Each class had a different focus: i) software maintenance and evolution, ii) software testing, and iii) reverse engineering of software requirements. Results show that students perceived features that make OSPs close to industrial projects, realized that their OSP tasks are close to the ones in industrial projects, and also faced difficulties typical of working with real world software. Moreover, students forged a view of the skills needed for their future professional success. We conclude that students realized that performing tasks in OSPs was a real world experience they took part, contributing to their background both for the competencies they acquired and the difficulties they had to overcome.

One of the main concerns in the software industry continues to be the development of high quality software. This concern will be exacerbated as software systems become more complex. The training of software developers continues to grow in academia since more institutions are offering software engineering (SE) courses. However, the list of topics that are expected to be covered in this course leaves little or no time for topics that focus on developing quality software, such as software testing and the use of testing tools.In this paper we describe an approach that non-intrusively integrates the use of software testing tools in SE courses. The cornerstone of our approach is the interaction students have with a Web-Based Repository of Software Testing Tools (WReSTT) that contains tutorials on testing concepts and testing tools. WReSTT employs both collaborative learning and social networking features that are attractive to students. We present the results of preliminary study performed in two SE courses that show how using the resources in WReSTT can potentially impact the students' understanding of software testing and the use of testing tools.

There are many ways to license open source software. Given the attention paid recently to the General Public License (GPL) and its latest version (GPLv3), you may be interested to know that there are other licenses that satisfy the principles of free and open source software without the confusion and polemics that surround the GPL. Other open source licenses have been approved by Open Source Initiative and adopted by commercial companies and by open source projects. Most of those other licenses are professionally written by lawyers to express clearly the licensing objectives of software copyright and patent owners and to ensure that they are valid and enforceable in all important jurisdictions. I wrote one of those licenses, the Open Software License. The third version of this license, OSL 3.0, was approved by Open Source Initiative in 2005. This article explains why it is a better license for software than the GPL. Software licensors choose their licenses based upon their particular philosophy and business models, and they intend their licenses to define the expected behavior of their licensees around the world. Because philosophies and businesses differ, so do licenses. In the open source world, there are two general categories of licenses: (1) Those licenses that allow derivative works of the software to be used and distributed as part of proprietary programs, and (2) those that require derivative works to be distributed under the same open source license as the original. The BSD license is the archetype of the first kind, what I call academic licenses. The GPL (version 2) is the most popular of the second kind, the so-called reciprocal or copyleft licenses. The license philosophies of these two categories of licenses are inherently irreconcilable, the first being compatible with proprietary derivative works and the other not, but they each make a valid point about the freedom to copy, change, and use software. I pass no judgment between them, since it is a licensor's right to choose a license for his own copyrightable works, not his lawyer's choice. The complete text (which is shorter than this article) of OSL 3.0 and its companion licenses is posted at www. rosenlaw.com/OSL3.0-comparison.pdf.

The Covid-19 pandemic forced many academic institutions around the world to switch to online teaching. This shift occurred suddenly and with little preparation and this method of instruction was named “emergency remote teaching”. This paper will describe the effects of emergency remote teaching on teaching a software engineering course at a Japanese university, showing how the online environment was used as an alternative to cancelling classes. Strategies for implementing active learning and for engaging students during this software engineering course will be highlighted. Based on the results and observations gathered during the teaching of this course, important conclusions will be drawn. They will constitute a starting point for planning and implementing future software engineering courses and for making sure that active learning continues to remain an essential part of the instruction process.KeywordsEmergency remote teachingActive learningSoftware engineering

The goals of computer science department and software engineering courses are not always clear as they could be, and exactly how much of a computer science curriculum should be spent on software engineering topics at the expense of topics with more immediate relevance to computer science majors is far from clear. Computer science students are sometimes skeptical about the relevance of software engineering course topics, particularly those who have had some experience in industry. They report that the techniques and procedures covered in standard software engineering texts are seldom used in industry. There is not enough communication between Industry and Academia, and graduates often must be re-trained for their new jobs. This is a proposal for a modification in the approach to software engineering education for computer science majors, and for clarification of the goals of computer science programs, and calls for procedures to increase the relevancy of computer science and software engineering courses to meet the needs of industry.

The primary goal of an introductory software engineering course is to provide a complete introduction to software engineering. Typically this includes concepts, terms, processes, tools, and history. However, for students to fully understand software engineering and be prepared for software development careers, courses must also consider the sociological and communication aspects, often called the socio-technical aspects. Unfortunately, these aspects are difficult to teach and do not receive much coverage in the most widely used software engineering textbooks. Faculty have used various approaches to address the socio-technical aspects. One popular method is to use role-playing exercises. The software engineering education literature contains many papers advocating role-play. However, these papers describe role-play integrated in semester-long projects and often provide little detail about the exercises. Using these published approaches in an existing software engineering course requires significant work by the instructor. This paper presents a set of ready to use role-play exercises that can be downloaded and easily integrated into an existing course. Student reaction is also reported.

In view of the demand for software professionals in current software industry and the teaching situation in universities, the necessity of researching and constructing software engineering course group is proposed; the basic principles of constructing software engineering course group is discussed, the knowledge system of software engineering courses group is analyzed, a three-segment two-lay course group is designed, the integration and division of the course contents is achieved, and the revision and recombination is promoted, the foundation is laided, in order to further improve the qua lit y o f personnel training and construction level of course group, and accomplish the scale effect of curriculum group construction.

Software engineering education is challenged by the need to convey practical experience in the context of a rich and large body of theoretical knowledge. This study investigates whether the use of open source projects can reduce the gap between theory and practice in undergraduate software engineering courses. Two qualitative case studies were conducted with students performing activities in an open source project, each one in a different course: software testing and software requirements. Results point out that the use of open source projects provides a concrete experience similar to industry experience, allows high cognitive engagement when performing tasks, favors understanding and content retention, and leads to the recognition of the usefulness of software engineering principles, techniques and methods.