Integrating Tools and Frameworks in Undergraduate Software EngineeringCurriculum

Christopher Fuhrman, Roger Champagne, Alain AprilDepartment of Software and IT Engineering

ETS, University of QuebecMontreal, Canada

{christopher.fuhrman,roger.champagne,alain.april}@etsmtl.ca

Abstract—We share our experience over the last 10 yearsfor finding, deploying and evaluating software engineering(SE) technologies in an undergraduate program at the ETSin Montreal, Canada. We identify challenges and proposestrategies to integrate technologies into an SE curriculum. Wedemonstrate how technologies are integrated throughout ourprogram, and provide details of the integration in two specificcourses.

Keywords-software engineering curricula; tools; frameworks;technology; integration

I. INTRODUCTION

Software engineers who have recently graduated are ex-pected to be familiar with technology that is being usedin industry. The Software Engineering 2004 Curriculumguidelines for undergraduate degree programs in softwareengineering [1] states: “Engineers use tools to apply pro-cesses systematically. Therefore, the choice and use ofappropriate tools is key to engineering.” Appropriate processtools are part of the essential areas that a curriculum mustaddress. Development frameworks and application program-ming interfaces (API) are also essential. In this paper, werefer to all these elements as “technologies”.

The areas where such technologies apply include (but arenot limited to) project management and planning, require-ments engineering, architecture and design modeling, cod-ing, and testing. Universities that educate and train softwareengineers therefore have a responsibility to prepare studentsto be familiar with the technologies that are appropriate inthese areas.

Several challenges exist which make fulfilling this re-sponsibility difficult for educators. As mentioned above,these technologies span a wide spectrum of areas, butthey are also constantly evolving. How does an educatordecide which technologies are appropriate to use in thecurriculum? Choosing the technologies is only part of theproblem. Educators must also acquire, teach, deploy andmaintain these technologies, despite the constraints presentin academic environments.

For example, some technologies have costly licenseswhich make them difficult to acquire. Even if an academic oropen-source license exists, there may be little documentation

about using the technology in an academic environment.On the other hand, many technologies are open-source andpopular, and provide educators with excellent resources thatfacilitate integration into the curriculum.

At many universities, faculty are under pressure to per-form research. The costly investment of time to integratethe newest technologies into undergraduate courses is notalways seen as the best return for their academic career.At the same time, some of the technologies that are usefulin research can also be useful in industry and therefore inthe curriculum. The expertise with the technologies is oftenpresent with the research faculty and their graduate students.An important question is how to leverage that expertise inan undergraduate setting.

Deploying the technologies in a learning environment iscomplicated by several factors. A particular laboratory spacecan be used by several courses; one physical workstation istime-shared and must run different technologies and maybeeven operating systems. Technologies are complex withpeculiar environmental requirements. Installations shouldbe tested properly in the learning environment before thestudents have access. A given lab space has a multiplicityof workstations, whose environments should be identical.Finally, to keep these environments free of malware, in-formation technology (IT) staff must apply patches to thesoftware regularly (ideally more often than once a semester).

In this paper, we present an experience report of more than10 years of teaching an undergraduate SE program at theETS in Montreal, Canada. After explaining the backgroundof our undergraduate SE program, we present our strategiesfor selecting and integrating technologies into the curriculumof this program. With respect to specific challenges we sharethe strategies that have proven successful to us and hopefullyuseful to administrators and faculty in SE programs atother universities. Finally, we give concrete examples oftechnologies that are integrated into courses, before we endthe paper with discussion and recommendations.

II. CONTEXT

The education system in Quebec is slightly different fromthe rest of North America. Students attend secondary school

978-1-4673-1067-3/12/$31.00 c© 2012 IEEEICSE 2012, Zurich, SwitzerlandSoftware Engineering Education

1195

for only five years, followed by a General and VocationalCollege (CEGEP), offering college-level programs for entryinto university (with two-year pre-university programs) or totrain students for technology-oriented careers, the latter be-ing roughly the equivalent of community colleges elsewherein North America. Therefore a student attending universitywould attend two years in pre-university CEGEP, followedby three or four years of university for an undergraduatelevel program. However, ETS is exceptional because itsprograms are for students who have gone through the three-year CEGEP programs (career/technology). A consequenceof this specificity is that all students accepted at ETSare technicians in a discipline related to their engineeringprogram. In the case of SE, this means the students havethree years of programming education and experience priorto their arrival at ETS. We are therefore able to teachconcepts such as OOD, OOA and design patterns duringthe first year, and software architecture during the secondyear, to name a few examples.

ETS is exclusively an engineering school, and is partof the University of Quebec network of universities. Theschool is relatively young, having been created in 1974. Asof October 2011, the total number of active students wasapproximately 6,300, including close to 5,000 undergraduatestudents, and a little over 1,300 graduate students. It isthe fourth largest engineering faculty in Canada, in termsof the total number of undergraduate students. The schooloffers undergraduate engineering programs in six disciplines,including SE, which is the focus of this paper.

All engineering programs at ETS integrate cooperative(co-op) education. Students must take three co-op terms,which last four months each. The school places 2,400students in 1,100 companies each year for these co-op terms.The students are paid during their co-op terms, which areimportant revenue sources for them during their studies,but also makes the relationship one of employee/employer.Because of incoming students’ technical background andthe co-op nature of our programs, ETS is considered avery “hands-on” school, which it is by design and mission.It is also worth noting that according to 2004 statistics,96% of enterprises in Quebec are Small and Medium-SizedEnterprises (SMEs), and 83% of those employ four peopleor less [2]. This reality must be taken into account in thedesign of our programs and courses, especially given the factthe Quebec’s economy includes 25% of Canada’s IT firms[2].

All engineering programs in Canada are subject to accred-itation by the Canadian Engineering Accreditation Board(CEAB), a federal organization. Moreover, all the studentsgraduating from our engineering programs are directly eligi-ble to become members of the Quebec Order of Engineers.We mention these points because they have direct impactson how we design our programs, which are audited everythree to six years by the CEAB, and are also audited by a

provincial government agency at roughly the same frequency(but not necessarily in sync).

The undergraduate program targeted by this paper is man-aged by the Software and IT Engineering Department,whichcurrently has 20 full-time faculty (averaging each 10 yearsindustrial experience), and roughly half that number insupport staff, all categories considered. There are currently430 active students in the SE program, and 240 activestudents in the IT Engineering program, for a grand total of670 undergraduate students. We mention the IT Engineeringprogram here because the same faculty are responsible forboth programs’ curricula.

Finally, all undergraduate courses at ETS have exercise orlab periods. Each course has 13 weekly three-hour lectureperiods, and 12 weekly two-to-three hour practical workperiods (typically in a computer lab).

III. CHALLENGES

A. Selecting Appropriate Technologies

When the undergraduate programs were put in place in2001, it was the faculty and Teaching Assistants (TAs) whochose the technologies to use in the practical part of thecourses they were responsible to create. Often, these tech-nologies were the same ones used in the research activitiesof the professors, and so they and their graduate students(who often are available to teach courses or laboratories)were also familiar with the same technologies.

Once courses are being taught, however, there is op-portunity for improvement via feedback from students andindustry. Figure 1 illustrates how this flow of expertiseand feedback cycles through the various stakeholders in theeducation process. Through course evaluations (formal andinformal), round-table discussions with students and indus-try, program accreditation, surveys (formal and informal),the department gathers feedback about the appropriatenessof the technologies that are integrated into courses.

Perhaps the most important link with industry comes fromfeedback via the co-op courses. During each of the threeco-op courses at ETS, students spend one semester in acompany, and that experience allows bi-directional sharing

Figure 1. Flow of expertise and feedback for choice of technologies

1196

of information about technologies. In their co-op work,students can suggest or use the technologies they learnedabout in their courses. In the other direction, students willrecommend to faculty (formally or informally) integratingtechnologies that they used in co-op work. This feedbackallows for evolution of courses in an iterative and agilefashion.

As an example, the first-year object-oriented analysisand design (OOAD) course was set-up in 2001 as a C++programming course using CORBA. By 2003 a group ofstudents had signed a collective petition stating that thetechnologies and practical exercises in that course were notuseful for their work in industry. They used examples fromtheir co-op work to make their point. A departmental deci-sion was made to re-design the practical part of the course, touse Java and Eclipse, as well as the Unified Process. Thesechanges influenced the methodology taught in the courseand even resulted in a change of textbook [3]. The projectwas transformed into a semester-long development of a web-based application, which is submitted in three iterations forevaluation.

Over the years, this OOAD course has continued to adaptto changing trends in technologies. The latest version ofthe project integrates Google Maps and Hibernate. Thesuggestions for changes often come from proactive studentsor Lab Assistants (LAs,) who are eager to prepare tutorialsor “Hello World” examples using these technologies. Thechanges are approved by faculty in charge of the courses. In-formal surveys of first semester students showed a relativelyequal proportion of students with backgrounds in .NET andJava. As a result, in the first-year OOAD course they arepermitted to code the semester-long project in either .NETor Java, with an understanding that LAs are prepared tosupport programming questions in Java.

When the SE program began, students were constantlyasking for a source-code version-control technology to usein the context of their practical course work. It was difficultto find a general solution to this problem, due to the largenumber of laboratory exercises it could be applied to. Open-source solutions such as CVS or academic-license solutionssuch as IBM Rational ClearCase both provide adequatefeatures for use in an academic environment. However, theyboth require a lot of administrative overhead to managethe creation and sharing of repositories used in the contextof any course. There was no technology to easily allowstudents to create their own repositories and manage sharingpermissions. This “problem” was turned into a businessopportunity for one of our early graduates, who produceda technology called Academic Version Control (AVC) thatis still in use today by many students at ETS. AVC has aweb-based front end allowing any authenticated student orfaculty to create and manage sharing of CVS repositories.

There are other aspects we considered when choosingtechnologies. A technology that’s only backed by a graduate

TA or LA is risky to integrate because these people willgenerally move on after a year or two. Many commercialtechnologies come with academic site licenses. However,our experience is that SE students want to be able to usetechnologies on their own computers (to work outside thelab space), and academic licenses do not always permitthat. Open-source technologies are usually excellent choices,especially when they are popular. They are likely to havetutorials or sample programs to flatten the learning curve.Commercial technologies with academic licenses do notalways come with good tutorials, in some cases because thevendor charges for training of the technology. Sometimesvendors allow instructors to sit-in for free on training ses-sions with a local company, provided the company doesn’tsee a conflict or there’s no non-disclosure agreement be-tween the trainer and the company.

B. Technical Challenges

As mentioned above with respect to choosing a technol-ogy, it takes technical expertise to successfully integrateit into the curriculum. It’s not necessary to know all thedimensions of a technology (as we discuss in the sectionbelow on Learnability). Similarly, undergraduate courses canbenefit from some of the more rudimentary features of atechnology.

Because of the large variety of technologies and theimportant number of courses that use them, our departmentopted for configuring many of the labs with either multi-boot hard drives or virtual machine capabilities. Severalof the workstations can boot Windows or Linux, or theMac workstations can run virtual machines with Windows.Obviously these workstations are more complex to configureand replicate, but the benefit is that a single seat can be usedfor multiple courses. One disadvantage to this approach isslightly less availability of lab spaces outside of reservedlab periods. To facilitate configuring the machines, ghostingof hard drive images is used as much as possible. IT staffvalidate the image of a configuration, and then it can bereplicated to all the destination machines overnight. Thisapproach also helps when security updates need to beapplied, usually once a month.

Having IT support staff who are knowledgeable andmotivated despite the complexity and wide range of thetechnologies is important. IT support in an academic envi-ronment is already a challenge, let alone trying to integratethese technologies into many undergraduate classes. IT staffwho are talented often enjoy challenges, and it’s been ourexperience that these kinds of challenges are positive. Wediscuss turnover of IT staff in the section on Politicalchallenges.

General IT support staff do not provide much integrationof the technologies into a course. For that, it’s back to theexpertise of the instructor or the LAs, which can mean alot of work. A strategy that works well at our university is

1197

that the administration funds project proposals that seek tointegrate new technologies into courses (or provide updatesto existing ones). A typical project is to pay a LA who’sfamiliar with the course to integrate/update some technologyinto a set of laboratory exercises. If the scope of the work islarge enough (e.g., development of a software technology tobe used by students), it can even be considered a co-op workterm for the student. In this case, the professor in charge ofthe course becomes an industrial supervisor.

C. Learnability Challenges

Many technologies are complex and have voluminous (orin some cases, poor) documentation. It is neither interestingnor feasible to have students learn all the functions of agiven technology in the context of a lab exercise. Therefore,technology learnability [4] is a challenge because it has animpact on the amount of time needed to accomplish thelearning goals of the lab sessions.

To overcome this problem, instructors first decide whichfunctions are applicable, and then they can provide task-focused tutorials that allow students to become familiarwith only the important functions of the technology in thecontext of the lab exercises. A tutorial can be in the formof a simple web page documenting the steps to follow toperform a task with a specific technology, or it can be avideo created using a free video capture tool that can belater annotated on Youtube. Sometimes such tutorials alreadyexist for popular open-source technologies. Students can beasked to familiarize themselves with the tutorials beforethe lab session, allowing instructors to focus more on theexercise. This strategy is analogous to a student preparing fordiscussions in a course by having already done the readings.

Apart from streamlining the laboratory exercises, tutorialsserve as a simple functional test of the installation of thetechnologies. IT staff can follow the steps in the tutorials (asif they were students) to verify that a technology has beenproperly installed in the lab environment. This is useful toavoid unpleasant surprises on the first day of the lab sessions.

D. Political Challenges

At many universities with tenure-track positions, a pro-fessor is implicitly (or sometimes explicitly) encouragedto invest most energy in research activities. Strategies thathelp reduce the risk of research faculty spending too muchtime on integrating technology into undergraduate programsinclude organizing capstone projects that have pedagogicaland technical goals, having a budget to hire undergraduateor graduate students who can perform the integration orupdates (clever LAs are great candidates), creating a positiveteam environment for LAs among several courses where they“own” the lab assignments, etc.

Another political challenge relates to evolutions in ITsupport. Traditionally, computer science departments kepttheir own IT support staff who were specialists in the areas

of technology needed in the department. However, with thedistillation of IT into everyday life, academic institutionsmay push to have IT support resources spread across morethan one academic department. Our experience is that somehuman resources can be shared, but it takes some who arededicated to the SE department if a level of quality is to beexpected when technology is diverse and integration is high.

This leads to the challenge of turnover in IT staff. Qual-ified IT staff are always at risk of leaving, perhaps becausesalaries or conditions are better elsewhere. The strategy wepropose is to accept that IT staff turnover is a reality. Muchlike students, talented IT staff in academic environments willnot be there forever. So it’s an ongoing necessity to identify,hire and train young talent to maintain the quality. Althoughthis is a difficult challenge, we found that by integratingmodern technologies into curriculum, the talented people aremotivated and interested by technological and environmentalchallenges.

Finally, integrating cloud computing into academia raisesa political issue, at least in some universities where there arerules or laws concerning the storage of student informationor intellectual property. Yale University decided to postponeswitching its mail services to Gmail [5], stating concernsabout the vagaries of laws and governments, given that everypiece of data is stored in three random data centers thatcould be in many places throughout the world. We mentionthis point because it extends to other features of Google,such as Google Apps, which look promising to integrateinto curriculum. Many students already collaborate on teamprojects in the cloud with these technologies, but they usetheir own private Google accounts. It is not clear whatlegal implications there are, if an institution would forcestudents to use these technologies by integrating them intoa curriculum.

E. Maintainability, Reuse and Deployment Challenges

SE educators have limited resources. In an effort tomaximize efficiency when preparing “courseware” (exam-ples, tutorials, assignments,...), we propose three importantaspects:

• the ability to reuse such artifacts across multiplecourses (for instance, examples or tutorials introducinga technology used in multiple courses);

• the effort required to maintain these artifacts over time;• the effort required to deploy these artifacts so students

gain access to them.From the reuse point of view, course material is very

similar to software components, e.g., finding the right “gran-ularity” for a reusable tutorial or example requires carefulconsideration, which requires more effort than developinga “one-shot” version of the same artifact. If an example isto be reused in a mandatory first-year course and also in asenior elective or even a graduate course, it must indeed becarefully designed and implemented. However, a reusable

1198

course material artifact should in turn contribute to reducedeffort when it is reused. The notions of coupling applieshere also. Each artifact should be as loosely coupled toothers as possible, in order to improve potential reuse andmaintainability.

Maintainability of courseware is especially importantwhen the courses discuss or use concepts or technologythat evolves rapidly, which is certainly the case in a lotof SE courses. From this perspective, course materials alsoexhibit similar characteristics to software. Once an educatorcommits to a certain technology, changing it becomes harderas time goes by, because of the time invested in using itand developing other artifacts (examples, tutorials) aroundit. Selecting a specific technology then requires carefulconsideration and outlook. It can be very frustrating to investsubstantial effort over long periods of time to support aspecific technology in courses and have that technologysuddenly disappear or become “unsupported”.

One would be tempted to think that with modern means(web sites, wikis, ...), deploying course materials is notan issue. One of the challenges we run into is deployingmaterials that are reused across courses. Our web server isstructured in a “one site (root) per course” fashion, for allkinds of valid reasons (access control, simplicity). However,in such a structure, examples, tutorials and simple web pagesthat are reused in multiple courses need to be copied in manyplaces, with the associated potential problems: the need tocopy any update to such material in multiple places, theproblems caused by forgetting one of these places, etc.

IV. OVERVIEW OF TECHNOLOGY INTEGRATION INUNDERGRADUATE SE CURRICULUM

In this section we present some of the technologies andwhere they are integrated into the curriculum. Figure 2shows how various types of technologies are integratedinto courses. The courses are presented in the table inchronological order relative to the SE undergraduate pro-gram, showing that students are exposed to technologiesused in industry as early as the first year. We included thespecial project and capstone projects that show almost anytechnology is optional, since those projects are individuallydecided and managed. They share a common element of amandatory project management technology, however. Thelist of technologies we include is not complete (becauseof space constraints), and it should not be construed as apromotion of those technologies or their suppliers.

We distinguish between technologies that are optional ormandatory in the context of a course. For example, in the OOAnalysis and Design course, students develop a web-basedapplication. The simplest solutions can be done with Javain Eclipse using Derby for a database. Some students preferto be more ambitious or use other programming languages(e.g., C# in .NET). However, all projects must show unittests using JUnit (or equivalent).

The following section describes in more detail how thesetechnologies are integrated into specific courses.

V. EXAMPLES OF TECHNOLOGY INTEGRATION INCOURSES

This section describes the technologies integrated in twocourses in our SE program. In previous sections we havementioned other courses as brief examples, but here weprovide details. The first example is a second-year coursetitled “Test and Maintenance”, and the second is a seniorelective titled “Distributed Object-Oriented Architecture”.In both cases, exposing students to realistic industrial en-vironments is a high-priority objective. Moreover, given thefact that a majority of our graduates are likely to work in asmall business environment, students are forced to performsome relatively “low-level” tasks, such as creating accountson servers and configuring their environments themselves,because they likely won’t have anyone to do it for them.This requires extra guidance and knowledge from the LAsand professors, but we concentrate on simple things we arecomfortable with.

A. Test and Maintenance Course

This course was first offered during the Summer 2008term. Ideally, a full course would have been created oneach of the main topics, but we could only add one course.The two halves were developed by two different professors,hence the two topics are discussed sequentially. The courseis offered twice a year to groups ranging from 50 to 70students. The pedagogical value of the strategy adopted inthe lab assignments for this course was the focus of anotherpaper presented elsewhere [6].

During the first half of the term, the practical objectiveis to expose students to a mature software maintenance en-vironment. Students are given a relatively small applicationthat has a user interface and uses a database. Its size is man-ageable (six Java classes, approx. 2,100 lines of code) and ithas the potential to highlight the salient issues in performingmaintenance on an application developed by someone else.It has several problems (poor separation of concerns, bugs,no documentation). The assumption is that an undisciplineddeveloper left the company with no documentation, andall that is available is the source code for the application.According to our experience, this is a realistic situation inlow-maturity SMEs. The actual maintenance work they mustrealize is described in Table II.

Following the maintenance part of the course, the focusswitches to software testing. The overall objective of thisportion of the lab is for students to acquire minimal expe-rience with basic black- and white-box testing techniques,and also with basic testing frameworks, by designing, im-plementing, executing, and reporting test results, at variouslevels (unit, integration, system).

1199

Figure 2. Courses (in chronological order) with integrated technology: X=mandatory technology, (X)=optional technology

This course uses a fairly rich set of technologies. When weselected them, our goal was basically to use at least version-control and ticket management systems. We also wanted touse analysis technologies to give various indicators on codequality, such as violations of programming standards. Aspreviously stated, the students must perform system admin-istration tasks, by design. At the time we were selecting thelab environment for this course, there was a trend towardsvirtualization in our department. We consequently decided tosupply each team (3-4 students) with a Linux-based virtualmachine (VM) hosted in a server room and containing someof the software they need pre-installed, but not completelyconfigured. Table I summarizes the technologies used forthis course, identifying those installed on the team VMs,on individual workstations in the lab, and in some cases inboth places. There are five lab assignments in this course,summarized in Table II (“M” = maintenance, “T” = testing).

In this specific case, there were initially few technicalchallenges. The professors developing the initial version ofthe course and lab assignments had experience with someof the technologies, were willing to invest effort to learnothers, and delegated part of the work (VM developmentand configuration) to a senior student in the context of hiscapstone project. This student had prepared a similar VMfor a student club. It took the student 25 hours of effort to

Table ITECHNOLOGIES: TEST AND MAINTENANCE COURSE

Workstation VM

Eclipse, CodeCover & Metrics plugins SVN (version-control)Apache ant (build technology) Trac (ticket management)Checkstyle, PMD, QAlab (code quality) Apache httpd (web server)Visual Paradigm (UML from code)

Junit, uispec4j (testing frameworks), Maven

prepare the VM. IT support staff took care of deploying theconfigured VMs on the institutional servers. The choice ofLAs was important here, and people who had used most ofthe technologies were selected in order to offer students ad-equate support in the lab. One of the technical challenges wedid not foresee was this environment’s scalability. Initially,this course was the only one to use VMs. However, as othercourses adopted the VM approach, there was a problem withhardware resources to accommodate this popular approach.To solve this problem we did two things: 1) added memoryto the servers, and 2) changed from the freeware VMs tothe Enterprise version (VMware Academic Program) whoseperformance is better. It took a competent analyst roughlytwo days of effort to configure the VMs for this course withthe new Enterprise virtualization package, but the analyst

1200

Table IILAB ASSIGNMENTS: TEST AND MAINTENANCE COURSE

Description and tasks Weeks

M1 - Environment setup: test VM, finish configuring Tracand SVN, create accounts for team members and customer,create roles and milestones, install application source code inSVN, generate quality analysis reports, create set of ticketsaccording to findings.

2

M2 - Reverse engineering and refactoring: produce likelydesign (UML diagrams), refactor code to improve maintain-ability, start fixing defects according to tickets raised, docu-ment all changes in tickets

2

M3 - Add new functionality: estimate effort for changes,obtain “customer” approval, perform changes on dedicatedSVN branch

2

T1 - Black-box testing: system level automated functionaltesting via the GUI with uispec4j

3

T2 - Test-Driven re-engineering and white-box testing:incremental layering of architecture, introducing unit and in-tegration tests

3

pointed out that it took him four to six weeks of full timeeffort to learn how to configure the Enterprise version ofVMware for another course (with good prior knowledge ofhow to configure the freeware version).

The learnability challenges were important in this case.A minority of students had been exposed to the technologiesprior to taking this course. Trac and SVN are two examplesof technologies that have a lot of documentation available,to a point it’s intimidating for a novice. We mitigatedthis by carefully looking at “mainstream” documentationfor these technologies, and provided students with welltargeted pointers to specific artifacts in the lab assignmentdescriptions. We did not supply any tutorials for this course,but designed the lab assignments in such a way that studentswould learn by actually performing targeted tasks. A simpleexample was designed for use in class and as an example inthe lab, to illustrate usage of the various eclipse plugins inthe testing portion of the course.

There were no political challenges to speak of in thiscase. Apart from the scalability problems mentioned aboveand the normal updates of technologies, there were nomaintainability, reuse or deployment problems either.

Upgrading the environment last summer required impor-tant effort from the professors and LAs also, mainly becausewe decided to start using Maven in this course. Mavenhas a relatively important learning curve, and everyonewas learning Maven during the upgrade. The core Mavenfunctionality is quite limited, and a multitude of plugins mustbe used, each having its usage and configuration specificities.Therefore, a course-specific Maven tutorial was written, insuch a way that students start with the source code andcompletely configured environment, and progressively writetheir Project Object Model (POM, main Maven build script)by copying and pasting sections from the tutorial. The mainMaven concepts are explained incrementally throughout this

tutorial. It was successfully used by a group of 70 studentsand was globally considered a positive addition to the course.Table III summarizes the effort put into upgrading the labenvironment and assignments this term.

Table IIIEFFORT: LABS UPGRADE, TEST AND MAINTENANCE COURSE

Who Effort Description(hours)

IT support 160-240 Learning to configure Enterprise VMware (notspecific to this course, but required)

IT support 12 Configuring and deploying the new VMs for70 students (26 teams)

Professors 100 Recruiting LAs, coordinating the whole effort,learning maven, writing a course-specific tuto-rial on Maven, validating lab assignments pro-duced by the LA, writing new lab assignments,writing and testing examples, evaluating newcandidate applications for the assignments

LA 90 Learning maven, configuring and testing all theplugins, testing new versions of applicationson the VM, writing new versions of the as-signments, validating tutorials produced by theprofs, training two other LAs

B. Distributed Objected-Oriented Architecture Course

This course is a senior-level elective. It was first offeredin 2003, and is since then offered once or twice a year togroups of 30 to 55 students. The core topic of the course ismiddleware, and the main objective is to expose students totwo important types of architectures in distributed systems,namely distributed objects (e.g. CORBA) and server-sidecomponent architectures (JEE).

In this course, the lab environment is deployed differentlythan the course described in the previous section. Thereis a single central VM used by the whole group, hostinga database server. All the other technologies required forthe lab assignments are deployed on individual computers(windows-based PCs) in the department’s computer labs.The environment is 100% Open Source, allowing students toreproduce it on their own computers. Moreover, the sharedVM is made available outside the university through a VPNconnection, enabling students to access the servers fromanywhere. This is an important aspect for students, allowingthem to work on their lab assignments outside their assignedlab period, even if the labs are used by other courses.

This course also uses multiple technologies. The selectioncriteria was somewhat different in this case. The CORBAimplementation that came with Sun’s Java SDK was usedinitially. We later switched to JacORB, mainly because itwas a more complete CORBA implementation, allowing usto cover a broader subset of CORBA concepts in the course.For the JEE part, when the course was initially created, theprofessor responsible for it had no experience in JEE, andrelied on experience from colleagues from elsewhere whosuggested a fully open-source set of technologies. Table IV

1201

summarizes the technologies currently used for this coursethat are installed on individual workstations. There are threelab assignments in this course, each lasting four weeks.Table V summarizes these assignments.

Table IVTECHNOLOGIES: DISTRIBUTED OO ARCHITECTURE COURSE

Technology

Eclipse IDE JEE edition with m2e and m2e-wtp integration pluginsJacORB (Java CORBA implementation)Apache Maven (project management)Apache Tomcat (JEE web container)PostgreSQL clients (psql, pgadmin)Hibernate, MyBatis (persistence)Spring framework (JEE development)

Table VLAB ASSIGNMENTS: DISTRIBUTED OO ARCHITECTURE COURSE

Description and tasks

1 - Introduction to distributed objects with CORBA: develop asimple distributed application on at least two hosts, given the interfacespecifications (IDL) for all remotely-accessible components.2 - Introduction to JEE: develop a subset of functionalities from lab1in JEE using servlets and JSP only (no EJB) and a relational database.3 - JEE and frameworks: re-implement the same application as inlab2, introduce at least one web framework and at least one persistenceframework. Framework choices left to students.

This course had numerous technical challenges over theyears. Initially, we used Sun’s reference implementation(J2EE 1.3) as our J2EE environment. The professor, whoalso served as LA, had no experience with this technology.Luckily, the IT support technician at the time did; hehad setup everything, and it just worked. Nowadays, theprofessor needs to give IT support detailed instructions onwhich technologies to install and how. This is done via adedicated page published by the professor on the course website, which is used by IT support, the students who wishto install the technologies on their own computers, and theprofessor himself, who uses this as a reminder for himselffrom term to term. This issue highlights the fact that it is hardto find IT support personnel that know ALL the technologiesrequired in a SE program.

One of the main technical challenges with this course’stechnology is that some of these technologies evolve rapidly(IDE, plugins). In the past two years, the professor spentbetween 20 and 40 hours each time the course is offeredjust to upgrade all the technologies and test them together.The course examples discussed below are especially usefulto test the environment from term to term.

IT support recently developed a technique to remotely addindividual Eclipse plugins (to an already deployed Eclipsedistribution) on all the lab computers without requiring acomplete re-imaging of the whole disk. This new capabilityproved very useful when we discovered we were missing a

crucial plugin in the labs, four weeks after the term hadstarted. Until recently, it was department policy that nochanges to the lab technologies could be performed duringthe term.

Since this course introduces a number of complex tech-nologies, learnability challenges were addressed by invest-ing an important effort (over many years) to supply studentswith small running examples, each consisting in a smallapplication highlighting a specific aspect of a technology.We currently use 11 such examples (2 for CORBA, 1 fordatabase access, 4 for “basic” JEE, 4 for JEE-related frame-works). Most of the examples were initially taken “as is”from the various technology distributions used or on theWeb. Some were modified, and all were extended with anAnt build script and instructions explaining the core conceptsthe example focuses on, and how to deploy it. Some of theseexamples are actually being reused by colleagues in othercourses.

To improve learnability, each lab assignment starts by“forcing” students (a small portion of the grade is assignedto this) to follow a tutorial (based on one of our examplesmentioned above). Each of these tutorials takes a full labperiod (two hours) to complete. We get sustained positivefeedback on these tutorials in the course evaluations. Theyalso enable us to confirm that the technologies are correctlydeployed, the students have correctly configured their envi-ronment, and they are ready to start the “real assignment”in a timely fashion (they must demonstrate their runningtutorial results the 2nd week of each lab assignment).

We recently introduced Maven in this course also. Thisyielded two important advantages, compared to Ant (whichwe were using before): 1) automatic resolution of externaldependencies (e.g. required external libraries) at compile/runtime; 2) deploying the examples on the course web sitesimply meant creating a ZIP archive containing the sourcecode, the Project Object Model (Maven script), and theREADME.html file (no external JARs). However, we neededto learn about another set of Maven plugins we hadn’tneeded in the other course (IDL compiler, JEE containerdeployment, database access). Replacing the Ant build scriptby its Maven equivalent for the 11 examples, learning Mavenin the process, took 70 person-hours this term alone (thiseffort is specific to this course). Since this course usesa simpler environment than the “Test and maintenance”course, the Maven tutorial developed for the other coursewas simplified for this course. This took 16 person-hours.Also, utility scripts and sample configuration files weredeveloped to ease the students’ learning of Maven andits use in the school’s infrastructure. The fact that studentaccounts reside on network drives required some adjustmentscompared to using a local drive, since by default someapplications (such as Maven) store useful files in the user’slocal account. Altogether, we spent (this term alone) 19person-hours in preparing the lab environment (setting up

1202

technologies, writing sample configuration files and relatedinstructions, testing technology deployment in the labs). Thisdoes not include IT support effort to deploy the tools in thelabs. Course evaluations revealed challenges with Maven,but also positive feedback. We consider Maven usage in thiscourse a positive experience in general, and will keep usingit with a few adjustments in the future.

There were no political challenges to speak of in thiscase either. One maintainability issue we regularly ran intoin the past was keeping the various tutorials up-to-date.This was complicated by the fact that we used to includescreen shots from the IDE, which basically changes everytime the course is offered. One practical way to reduce thisproblem is to refer to menu item sequences instead of screenshots. We find this easier to maintain over time. In termsof deployment, adding Maven to the technology set greatlyfacilitated deployment at two levels: the examples suppliedto students via the course web site, described earlier, andalso the submission of lab assignments to the LA. In bothcases, external libraries need not be included, since they areresolved and downloaded by Maven at compile time. For thelab assignments, students are forced to use Maven, whichimposes a standard project (folder) structure. Compiling,running and grading the assignments is much easier, sinceall their submissions have the same structure.

VI. RELATED WORK

Different proposed curricula in SE have been studied byMishra et al. [7], who recognize the importance for tech-nologies. They suggest that it is in the practice courses (e.g.,capstone projects) where the students discover and explorenew technologies and development methodologies. In ourapproach, technologies are integrated into the majority ofSE courses, although not to the same extent. Rusu et al. [8]show that having faculty with strong ties to industry whosupervise capstone (senior year) projects is an effective wayto improve student implication in real-world SE projects.

Toth points out [9] that SE programs must go beyondteaching just theory and increase on practical aspects. Heproposes using open-source projects as the basis for capstoneprojects. Although this approach is excellent for capstoneprojects, in curriculum where co-op work is done as earlyas the first year, practical work must be introduced earlierif students are to be ready for their industrial contact.Boloix et al. discuss tool learnability [4], which cannot beignored especially with some of today’s very sophisticatedtechnologies.

Chen et al. [10] consider the benefits of cooperativeeducation (co-ops) where students spend time in industryworking on real-world software projects. The authors stressthat not only do students gain useful work experience thatrelates back to their theoretical work, but it also improvesrelations with industry. Reichlmay [11] documents the ad-vantages of cooperative education, but also discusses the

benefits in terms of faculty and research collaboration. Sincestudents and faculty are the forces of change who are closestto a curriculum, it makes sense that they be connected toindustry.

In terms of specific tools, Skevoulis and Makarov [12]conclude that by using appropriate formal methods tools incourses, students learn from them and have better attitudestowards formal methods. In [13], Fuhrman demonstratedthat a tool supporting lightweight modeling and formalmethods can be used to help interpret informal (real-world)specifications in an undergraduate telecommunications soft-ware course (see “Telecom SW” in Figure 2). This coursehas since been updated with technologies supporting theSpecification and Description Language (SDL) that providelightweight model-checking.

For integration of version-control technologies into cur-riculum, Parada et al. [14] propose a solution using a popularsource-code control technology (Subversion). They providean interface to instructors to create workspaces for students.As far as we can tell from the paper, this technology is notdesigned to allow students to create their own workspaces.Milentijevic et al. [15] consider the benefits of using version-control in project-based learning. Their solution documentstwo roles, supervisor and student, and it’s the supervisor whomust define the project.

VII. CONCLUSION

Many different tools and frameworks are used in practicein SE. In an ideal world, all students would graduate with agood understanding and knowhow related to the use of manyof theses tools. In this paper, we discussed our experience inintegrating tools in various SE courses. After describing ourcontext, we described various types of challenges faced bythe many stakeholders involved in such technology integra-tion in curricula. These challenges are the main ones we havebeen facing for 10 years in our SE program. We highlightedthe numerous aspects to consider when choosing toolsand identified the main technical, learnability, and politicalchallenges. We also discussed issues such as course materialmaintainability, reuse and deployment. We gave an overviewof the numerous tools deployed in our SE program, anddescribed in some details the specific challenges we facedwhen integrating tools in two courses using rich technologysets, including recently added technology (Maven, VMwareupgrade) and the associated effort required by the variousstakeholders involved. The effort data reported here couldperhaps be considered an upper bound, as the professorsinvolved invest more time than average in the preparation oftheir lab environments.

Students collectively know a lot about technologies, andthey like working with technologies. They are a valuablesource of information about the latest technologies, and interms of knowledge, they will always outnumber the feweducators teaching any given course and labs. Open and

1203

honest discussion with students about tools should be en-couraged in class, via course-related discussion groups, andtheir opinions should be carefully considered by educators.In our context, the fact that students take three co-op coursesadds even more feedback of this nature. These co-op coursesin turn force us to insist on tools throughout the program,including in the early stages, so that students can bring somevalue to the organizations that hire them for their co-opterms.

We are convinced that pre-existing industrial experienceof faculty, TAs, and IT support staff is essential withtechnology integration in curricula. Another helpful aspectis the existence of resources (a budget) to maintain andevolve laboratory environments. The LAs assisting us inthe upgrades described here were paid for their work bythe School. The professors and IT support staff’s time isconsidered part of their normal work load.

Another aspect to keep in mind is that most of ourgraduates will work locally after they finish school. Ourentire program strategy is very much aligned with ourlocal context, and we assume this would be true for manyuniversities.

Table VI summarizes the recommendations statedthroughout the paper.

Table VISUMMARY OF RECOMMENDATIONS

ID Recommendation

R1 Leverage experience from research environments.R2 Acquire frequent feedback from industry/students/researchers re-

garding technology fitness.R3 Identify a faculty evangelist/expert for important technologies.R4 Invest in competent, reliable, motivated people to support the tools.R5 Prioritize core features of technology for integration in courseware.R6 Use Open Source or academic license tools when possible.R7 Use tools with rich user documentation and examples, or be

prepared to produce them.R8 Have a heterogeneous environment (operating systems, program-

ming languages).R9 Expect turnover in IT, but continue to grow it up from the base.R10 If cloud computing is considered, get fluent with the various laws

and university privacy rules.R11 Design easily maintainable and reusable courseware.R12 Avoid screenshots, as they age too quickly.R13 Think about scalability early if virtualization is to be used.R14 Provide secure access to computing resources outside the campus.R15 Impose the “hello world” tool demo as the first lab assignment.

ACKNOWLEDGMENT

The authors would like to thank Patrice Dion, PierreDumouchel, Francois Coallier, Lucie Caron, Sandra Ranger,Christian Desrosiers, Luc Duong, Nadjia Kara and Carlos-Teodoro Monsalve, who supplied information that was usedin this paper. We also wish to thank the anonymous review-ers, whose comments allowed us to improve this paper.

REFERENCES

[1] IEEE Computer Society, “Software Engineering 2004: Cur-riculum guidelines for undergraduate degree programs in soft-ware engineering,” http://sites.computer.org/ccse/, Aug. 2004,date accessed Oct. 20, 2011.

[2] Government of Canada - SME Financing Data Initiative,“Small business financing profiles,” http://www.sme-fdi.gc.ca/eic/site/sme fdi-prf pme.nsf/eng/h 02088.html, date ac-cessed Oct. 22, 2011.

[3] C. Larman, Applying UML and patterns: an introduction toobject-oriented analysis and design and iterative develop-ment, 3rd ed. Upper Saddle River, N.J.: Prentice Hall PTR,2005.

[4] G. Boloix and P. N. Robillard, “CASE tool learnabilityin a software engineering course,” IEEE Transactions onEducation, vol. 41, no. 3, pp. 185–193, Aug. 1998.

[5] D. Tidmarsh, “ITS delays switch to Gmail,”http://www.yaledailynews.com/news/2010/mar/30/its-delays-switch-to-gmail/, Mar. 2010, date accessedOct. 20, 2011.

[6] R. Dupuis, R. Champagne, A. April, and N. Seguin, “Exper-iments of adding to the experience that can be acquired froma software project course,” in QUATIC ’10, Sep. 2010.

[7] A. Mishra, N. Cagiltay, and O. Kilic, “Software engineeringeducation: some important dimensions,” European Journal ofEngineering Education, vol. 32, no. 3, pp. 349 – 61, 2007.

[8] A. Rusu and M. Swenson, “An industry-academia team-teaching case study for software engineering capstonecourses,” in Frontiers in Education Conference, 2008. FIE2008. 38th Annual, Oct. 2008, pp. F4C–18 –F4C–23.

[9] K. Toth, “Experiences with open source software engineeringtools,” IEEE Software, vol. 23, no. 6, pp. 44–52, Dec. 2006.

[10] J. Chen, H. Lu, L. An, and Y. Zhou, “Exploring teachingmethods in software engineering education,” in 4th Interna-tional Conference on Computer Science Education, Jul 2009,pp. 1733 –1738.

[11] T. J. Reichlmay, “Collaborating with industry: strategies foran undergraduate software engineering program,” in SSEE’06.New York: ACM, 2006, pp. 13–16.

[12] S. Skevoulis and V. Makarov, “Integrating formal methodstools into undergraduate computer science curriculum,” inFrontiers in Education Conference, 36th Annual, Oct. 2006,pp. 1 –6.

[13] C. P. Fuhrman, “Lightweight models for interpreting informalspecifications,” Requirements Engineering, vol. 8, no. 4, pp.206–221, 2003.

[14] G. H. A. Parada, A. Pardo, and C. D. Kloos, “Towardscombining individual and collaborative work spaces under aunified e-portfolio,” in ICCSA’11, 2011, pp. 488–501.

[15] I. Milentijevic, V. Ciric, and O. Vojinovic, “Version controlin project-based learning,” Comput. Educ., vol. 50, pp. 1331–1338, May 2008.

1204