Selecting Open Source Software Projects to Teach Software Engineering

Selecting Open Source Software Projects to Teach Software Engineering Thérèse Smith, Robert McCartney, and Swapna S. Gokhale Lisa C. Kaczmarczyk Department of Computer Science and Engineering Consultant University of Connecticut, Storrs, CT 06269 San Diego, CA 92130 [tms08012, robert, ssg]@engr.uconn.edu [email protected] ABSTRACT for careers in the software industry. An overwhelming num- Aspiring software engineers must be able to comprehend ber of software engineering activities involve understanding and evolve legacy code, which is challenging because the and evolving existing, legacy code. Comprehension of such code may be poorly documented, ill structured, and lacking legacy code may be difficult because it could: (i) have been in human support. These challenges of understanding and subject to many fixes and enhancements, (ii) be poorly writ- evolving existing code can be illustrated in academic settings ten, (iii) have little to no documentation, and/or (iv) lack by leveraging the rich and varied volume of Open Source support. Computing students must therefore be trained to Software (OSS) code. To teach SE with OSS, however, it \reverse engineer" design decisions and their rationale from is necessary to select uniform projects of appropriate size such code, often under serious time and resource constraints. and complexity. This paper reports on our search for suit- A major difficulty in highlighting comprehension and evo- able OSS projects to teach an introductory SE course with lution challenges to SE students is to find pre-existing code a focus on maintenance and evolution. The search turned that has characteristics similar to that of industrial code out to be quite labor intensive and cumbersome, contrary but is commensurate with students' preparation and back- to our expectations that it would be quick and simple. The ground. The rich and diverse Open Source Software (OSS) chosen projects successfully demonstrated the maintenance projects can readily supply such pre-existing code [6]. It challenges, highlighting the promise of using OSS. The bur- can also provide a context to practice design, development, den of selecting projects, however, may impede widespread and testing skills. OSS-based SE projects will force students integration of OSS into SE and other computing courses. to comprehend sparsely documented and/or poorly written code. OSS can thus be leveraged to emulate industrial challenges in academic environments. Categories and Subject Descriptors Our objective was to integrate OSS projects into our D.2.7 [Software Engineering]: Distribution, Mainte- sophomore-level SE course. Because OSS projects exhibited nance, and Enhancement; K.3.2 [Computers and Edu- large variability in terms of size, complexity, and quality, cation]: Computers and Information Science Education our greatest obstacle was to select suitable projects. The projects could not be too large or complex because students General Terms would not be able to understand them well enough to extend them. These projects also could not be too small or simple Documentation, Design, Experimentation because the students would not find it necessary to use SE principles, rather they could fall back to the disorganized Keywords generate-and-test approaches that were sufficient in the in- Software Engineering, Maintenance, Program Comprehen- troductory courses. Given these constraints, we sought to sion, Open Source manually identify, evaluate, and prepare projects for integration. This paper describes how our selection effort was 1. INTRODUCTION AND MOTIVATION fraught with unexpected challenges and was labor intensive. The selected projects, however, provided opportunities for The need for skilled software engineers has compelled deep involvement with the code, meaningfully highlighting nearly every computing curriculum to include Software En- the maintenance difficulties. Our experience thus suggests gineering (SE) as a mandatory course. The objective of that in order to use OSS for SE instruction, the burden of this SE course is to train students in principles and prac- selecting and preparing projects must be alleviated. tices of modern software engineering and to prepare them This paper is organized as follows: Section 2 discusses the Permission to make digital or hard copies of all or part of this work for personal or promise of OSS. Section 3 compares OSS repositories . Sec- classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation tion 4 presents project selection process. Section 5 describes on the first page. Copyrights for components of this work owned by others than the how the chosen projects met course objectives. Section 6 author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or surveys related work. Section 7 concludes the paper. republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. SIGCSE’14, March 3–8, 2014, Atlanta, GA, USA. 2. OSS: PROMISE AND PERILS Copyright is held by the owner/author(s). Publication rights licensed to ACM. ACM 978-1-4503-2605-6/14/03 ...$15.00. The OSS revolution is having a lasting impact on the way http://dx.doi.org/10.1145/2538862.2538932. software is developed, disseminated, and adapted. This is 397 evident from the myriad of OSS projects already available, plement an enhancement of their choice. The students were and the pace at which software engineers contribute to the expected to work methodically and document their activi- development of these projects. This revolution has thus cre- ties systematically, especially, those undertaken to complete ated easily accessible, exponentially growing [9] volume of their enhancement. Given the background and skills of our code, some of which can be used as example code in SE ed- students and the objectives of the course, we devised the ucation. Popular OSS repositories such as Sourceforge [29], following preliminary criteria: Freecode [12], CodePlex [7], and W3C [33] host more than 200,000 projects. We use these repositories simply as code • Programming Language (PL): The projects must be sources; students do not contribute back to them. programmed completely in Java because it was the OSS projects span a variety of domains such as tools for only language known by all of our students. software development, financial analysis, security and net- working, data manipulation and visualization, audio and • Code Size (CS): Project size should be approximately video engineering and text editing, operating and database 10,000 lines; smaller projects may not adequately em- systems, and games and entertainment [29]. These projects ulate maintenance difficulties and larger ones may be target common platforms including Windows and Linux and beyond our students' capabilities [20]. are written in languages such as C, C++, Perl, Fortran, • Team Development (TD): Projects with a team were Python, Java, Tcl, Objective-C, Ada, and Php. Although desirable, for possibly quick resolution of issues. the OSS development process appears ad hoc, many projects are completed successfully with rich functionality and high • Buildability (BD): Projects should build within one to reliability because their latent social structure allows the two days to preserve focus on understanding and en- projects to grow in an organized manner [2, 31]. Moreover, hancing the code. because most engineers participate in OSS to build reputa- tion, or for self-development [23] and altruistic reasons, they 3.2 Exploration of Repositories may be inherently committed to SE principles, which may We searched several OSS repositories subject to PL, CS, lead to projects that are carefully designed, engineered, and TD, and BD criteria to narrow a large pool of candidate maintained. OSS projects may thus exhibit varied char- projects. We believed that these preliminary criteria would acteristics and quality similar to industrial systems, even be easy to assess; obviously it should be possible to deter- though their requirements processes may differ from that of mine code size, programming language and whether a team traditional software systems [26]. These projects can thus was involved with a project with minimal effort. Also, we provide a valuable resource for teaching SE. expected most OSS projects to be close to building. Con- The rich diversity of OSS systems, however, presents one trary to these expectations, however, we found that mostly of the greatest hurdles in teaching with these projects. All large projects, which were beyond the code size criterion chosen projects must be of comparable difficulty and com- built easily and many smaller projects with acceptable code plexity. Independent selection by students from OSS repos- sizes failed to build. Therefore, we deferred examining for itories is not only unlikely to produce that result but it may buildability and describe our findings in applying only the also be inordinately time consuming. Therefore, teaching CS, PL and TD criteria to the OSS repositories. SE with OSS will require identification and evaluation of a collection of suitable projects. We seek a collection because • Apache: Apache hosted many projects with excellent it improves the chance that students will find an interesting quality, sizeable communities, noteworthy documenta- project and also minimizes cross-group collaboration. Such tion, and passing the BD test. However, the

Load more