SEKE 2012 Proceedings - Knowledge Systems Institute

and tedious. Specifically, we observed that many tools
disappointed in delivering their promised functionality.
Moreover, the tool that was ultimately chosen because
it performed smoothly during evaluation, posed unexpected
problems during actual laboratory assignments.
We disseminate our experiences and lessons through
this paper, hoping to inform others who may wish to
undertake a similar evaluation.
The paper is organized as follows: Section 2 outlines
the selection criteria. Section 3 presents tool selection
and evaluation. Section 4 shares our experiences and
students’ reactions. Section 5 summarizes the lessons
learned. Section 6 surveys contemporary tools. Section
7 concludes and offers future directions.
2 Selection Criteria
Various types of tools may be used in SE depending
on its emphasis, which in turn depends on when the
course appears in the curriculum. SE may be offered
according to two broad models, namely, “SE early”
and “SE late”. In the early model, SE is offered to
sophomores and juniors, and most often represents the
students’ first opportunity to get acquainted with the
tools used in the construction of software systems. In
the late model, SE is offered to seniors and may even
be merged with the capstone project. SE late students
may have had opportunities to acquire experience in
the processes and tools necessary to build software.
The tools in the SE early approach may cater towards
foundational software development skills, including
requirements analysis, design, testing, and configuration
management. On the other hand, the late SE
course may introduce students to specialized, sophisticated
tools such as those used for debugging, defect
tracking, cost estimation, automatic code generation
and project management. Our approach is SE early
and we sought to expose our students to configuration
management and reverse engineering tools. To shortlist
these two types of tools for further experimentation, we
defined the following criteria:
1. Integrated Environment: Integrated development
environments (IDEs) are recommended in
the industry [10] because such environments, where
a collection of tools interoperate [24], can support
cross-process improvements [10]. Studies also show
that practicing software engineers prefer integrated
tools [18]. Finally, academics report that teaching with
integrated tools can be less distracting from the course
objectives [19]. Thus, we choose to teach SE using an
Integrated Development Environment (IDE).
Our choice of IDE is Eclipse because students have
used it in a previous course, thus we prefer tools that
integrate with Eclipse. Even though we may pick tools
from multiple sources, our first criterion is that the
impression of an integrated workstation for interaction
with the code must be maintained through Eclipse and
its plug-ins. Moreover, the plug-ins should work with
Java, which is the language of the course projects, since
it is the only one commonly known to the students.
2. Open Source: To teach students code comprehension,
maintenance and evolution, a supply of code
which represents legacy software is necessary. Aspects
of this representative software include that it is written
by someone else, preferably a team, has perhaps only
moderately good documentation and design, and does
not follow a uniform style. A certain level of complexity
is desirable, as is appeal to the students. The course
projects are based on open source software because it
offers a rich volume of code that exhibits these characteristics.
Therefore, a significant criterion is that the
tools themselves are open source.
3. Unified Process (UML): The course exercises a
software process, similar to IBM Rational Unified Process
[34], because of UML’s industrial and academic
popularity [16, 29, 33]. The students are expected to
learn class and sequence diagrams. Thus, the chosen
tools should be capable of drawing, and wherever appropriate,
extracting these diagrams from the code,
which we refer to as “reverse engineering”. Static class
diagrams can be extracted without executing the code,
whereas, dynamic sequence diagrams can be extracted
only by executing the code.
3 Tool selection and evaluation
We short listed several configuration management
and reverse engineering tools for further exploration.
This section summarizes these tools and their evaluation
results, subject to the criteria defined in Section 2.
CVS, SVN and Git were the candidate configration
management tools. We included CVS [5] because it
was available in Eclipse as installed in the lab, and
SVN [27] because it was familiar to the course staff.
Although Git [14] was neither installed nor familiar, we
included it because it was comparatively more modern.
Finally, we chose Git and Eclipse plug-in EGit because
of their distrbuted design, scalability, and support from
a worldwide community [14]. This distributed design
would allow students to update from one another, independently
of any central repository.
163