A Software Project Management Portal to Meet Educational Needs
Total Page：16
File Type：pdf, Size：1020Kb
DrProject: A Software Project Management Portal to Meet Educational Needs Karen L. Reid Gregory V. Wilson Dept. of Computer Science Dept. of Computer Science University of Toronto University of Toronto [email protected] [email protected] ABSTRACT efforts and use their time more efficiently. They give in- DrProject is a web-based software project management por- structors a concrete environment in which to teach basic tal that integrates revision control, issue tracking, mailing teamwork skills such as time management and communica- lists, a wiki, and other features. Unlike other such systems, tion, as well as a hands-on starting point for teaching larger DrProject is specifically tailored to the needs of undergrad- software engineering issues such as maintenance and release uate teaching and team programming assignments. We de- management. scribe the pedagogical motivations for DrProject and our More importantly, these tools encourage truly collabora- experiences with it to date. tive work. Many student teams divide the work into pieces, then toil away individually until a “big bang” integration shortly before the due date. By helping students see that Categories and Subject Descriptors software development is a social activity, rather than an anti- K.3 [Computing Milieux]: Computers and Education; social one, use of collaborative tools may help attract and D.2.6 [Software]: Software Engineering, Programming En- retain students from at-risk groups [7]. vironments The only way for students to master these tools is through practice. However, the setup overheads of industrial-strength General Terms tools are often intimidating. What’s more, many of their features are over-engineered for six-week assignments un- Management dertaken part-time by teams of three to five students. As a result, many students come away from their first contact Keywords with these types of tools believing that they make life more Education, Software tools, Software Engineering, Course- difficult, rather than less. ware Conversely, existing systems lack capabilities that are cru- cial in classroom settings: there is no easy way to create 1. INTRODUCTION dozens of similar projects at once, and many systems do not hide any information, for the simple reason that “open” Real-world software engineering is a collaborative activ- projects don’t need to do so. ity: programs are designed, developed, and maintained by We therefore decided to build a portal that would be for teams. Learning how to work productively with others should teams what DrJava [1] and BlueJ [8] are for individuals: sim- be a central part of undergraduate education in software en- ple enough to learn in an hour, but with the key components gineering [2, 4]. of full-featured systems. Our goal was not to build a course Project teams in industry, academia, and the open source management system—grading, lecture notes, and so on are community are increasingly reliant on web-based project well handled by existing courseware—but rather to create a management portals [5]. The best known of these, Source- simplified, realistic, and above all compelling alternative to Forge [10], currently hosts over one hundred thousand pro- full-strength software project management systems. jects and over a million users. It, and imitators like GForge, CollabNet, and CodeHaus, are now as important to devel- opers as IDEs like Eclipse. 2. REQUIREMENTS Learning how to use such portals should therefore be a Software project management portals offer a common core central element of software engineering education. In class- of features [3]: room settings, these tools help students coordinate their • A version control system is a tool that coordinates changes to shared files, such as source code, while recording the history of those changes. Most such sys- Permission to make digital or hard copies of all or part of this work for tems keep the master copies of the files in a networked personal or classroom use is granted without fee provided that copies are central repository; developers work in personal mir- not made or distributed for profit or commercial advantage and that copies rors of this while periodically synchronizing with the bear this notice and the full citation on the first page. To copy otherwise, to repository. We have successfully introduced version republish, to post on servers or to redistribute to lists, requires prior specific control into our second-year programming courses as permission and/or a fee. SIGCSE’07, March 7–10, 2007, Covington, Kentucky, USA. a first step in learning tools to support good working Copyright 2007 ACM 1-59593-361-1/07/0003 ...$5.00. practices [9]. Most industrial-strength portals include a repository 3. SYSTEM EVOLUTION browser that allows users to see the current and past Web-based project management systems are invariably state of files, change sets, etc. This is almost always built using a three-tier architecture. The user’s web browser read-only, since allowing people to update and commit communicates with a web server, which passes HTTP re- through their web browser raises security issues. Users quests to a CGI or servlet “engine” that uses a relational check out and commit files to the repository using sep- database for persistent storage. The engine integrates with arate standard tools. a pre-existing version control system, such as CVS or Sub- version; depending on the system’s capabilities, it may also • An issue tracking system is used to store bug reports, integrate with a mail transfer agent, authentication services change requests, ideas for enhancements, and general such as LDAP or Kerberos, and so forth. to-do items in a central database. These systems typ- In 2003-04 we developed three prototypes of DrProject ically allow users to classify entries (often called “tick- using this architecture: one from scratch using Java Server ets”) by priority, keep track of who is supposed to be Pages, a second that modified GForge, and a third (also working on them, and so on. They usually also al- from scratch) using Hibernate, Tapestry, and other “New low users to associate tickets with deadlines, so that Standard Model” Java tools. These experiences were disap- project members can quickly get an overview of what pointing: the Java tools’ learning curve was so steep that needs to be done by when. it would have been impossible to maintain the system with student labor, while there were so many security problems • A wiki, which acts as a shared online whiteboard for in GForge that further work seemed pointless. the project. We started over in 2005, using a young open source tool created by Jonas Borgstr¨omand Daniel Lundin called Trac • Mailing lists, so that team members can communicate. [11] as our starting point. Trac consisted of roughly 11,000 • A search engine to help users find project-specific in- lines of Python, plus a further 3000 lines of HTML tem- formation. plates. Five undergraduate students worked full-time on the project in the summer of 2005; progress was rapid, and • Some form of account management. Most systems we deployed the system in three courses in the fall of that support self-registration; some also allow users to join year. Further work was done in January 2006, and two more projects on their own, while others leave that in the undergraduates worked on it again in the summer of 2006. hands of the project administrator. DrProject 1.1, released in September 2006, contains 21,250 lines of Python source (including blank lines, comments, and • Extra features, such as status dashboards showing pro- embedded documentation strings), a further 13,000 lines of ject progress over time, continuous build systems that test code, and 3600 lines of HTML templates. It is built recompile code and rerun tests every time a change is on top of a Postgres database and Subversion repositories. checked in, and per-project blogs. As the screenshot in Figure 1 shows, it offers all of the key features identified earlier, as well as tagging (to facilitate These features are all as useful in courses as they are in search) and a timeline of recent events. real life, with the exception of account management. Ed- ucational institutions typically have well-developed systems 4. DRPROJECT FEATURES for creating student accounts, checking the strengths of pass- Each project in DrProject 1.1 has the following compo- words, locking down accounts when courses are finished, and nents: so on. These systems also typically handle access control is- sues, for example by ensuring that student accounts are in Wiki The wiki ties all the components of DrProject to- the right Unix groups for particular courses. We therefore gether. Using wiki syntax, links can easily be created decided that account creation and management should not to refer to a specific ticket, changeset, mail message, be part of our system: users are required to have an account or wiki page. on the underlying host in order to use DrProject. Subversion repository Each project has a separate Sub- However, industrial-strength systems lack some features version repository. This helps isolate projects from one required for classroom use. The first is customizable roles another and also simplifies revision numbering. and permissions. Most open source projects divide the world into administrators, developers, and viewers. In courses, Tickets We tried to minimize the number of fields in a however, we need to differentiate between professors, TAs, ticket to make it as easy as possible to use while still students working on particular projects, students who can providing the key features. For example, tickets can view those projects but not alter them, students for whom be in only two states, open or closed. We eliminated those projects are opaque, and so on. More importantly, other possibilities such as rejected, completed, and re- we need to be able to customize these permissions to fit the opened, on the grounds that students were unlikely pre-existing rules of different educational institutions.