The Journal of Systems and Software 74 (2005) 113120

www.elsevier.com/locate/jss

Developing and using a web-based project process throughout

the software engineering curriculum
a,* b
Donald J. Bagert , Susan A. Mengel
a
Department of Computer Science and Software Engineering, Rose-Hulman Institute of Technology, Terre Haute, IN 47803-3999, USA
b
Department of Computer Science, Texas Tech University, Lubbock, TX 79409-3104, USA
Received 1 September 2002; received in revised form 1 February 2003; accepted 1 September 2003
Available online 30 December 2003

Abstract

In order to facilitate the study and use of software process, which is essential to the education of future software professionals, a
standard and tailorable project process has been developed over the last ve years at Texas Tech University for use in both
undergraduate and graduate curricula, with a total of 12 courses involved. The process is entirely web-based, and includes a
complete set of HTML document templates in order to facilitate the creation of project artifacts which are posted to the course web
page. This method enhances communication between team members, including distance education students, and between the project
team and client. The project process has received positive feedback from all stakeholders involved.
This paper discusses the benets of the web-based project process, its relation to curriculum models, and plans for a more formal
assessment of the process. The portability of process to other institutions is also discussed, with an example provided involving the
software engineering courses at the Rose-Hulman Institute of Technology.

2003 Elsevier Inc. All rights reserved.

1. Introduction grams at Texas Tech, there are 12 semester-long courses

Virtually all aspects of software engineering (SE) can
be found within the software development process.
Furthermore, the use of a standard software develop-
ment process within a software organization has become
increasingly common over the past 1015 years. There-
fore, not only is the study of software process essential
to the education of a future software professional, but
the use of a standard, tailorable process throughout a
computer science and SE curriculum can be benecial in
understanding how such a process can be used in dif-
ferent ways within the same software organization.
The Department of Computer Science at Texas Tech
University (TTU) has used such a strategy as part of the
development of its curriculum models. Between the
Master of Science in Software Engineering (MSSE) and
Bachelor of Science in Computer Science (BSCS) pro-
* comes of the web-based process, and a presentation of the
Corresponding author. Tel.: +1-812-877-8327; fax: +1-812-872-
6060.
E-mail addresses: don.bagert@rose-hulman.edu (D.J. Bagert),
susan.mengel@ttu.edu (S.A. Mengel).
that deal with SE, from fundamentals through advanced
concepts. Five years ago, a standard software project
process was developed that is now present throughout
the SE aspects of the curriculumincluding capstone
courses on both the undergraduate and graduate level
as well as classes that are more lecture-oriented, but
require assignments that use the project process.
In addition, this software process is completely web-
based. All project artifacts are posted to the course web
page, which enhances communication between team
members, some of which are taking the course itself
through the Internet (the MSSE degree is oered via
distance education). This also facilitates interaction with
the project clients, who often work for companies lo-
cated outside of the community where TTU is located.
This paper will provide some background concerning
the use of project processes in SE curricula, the BSCS and
MSSE curricula at Texas Tech, the objectives and out-
details of the Texas Tech software process and document
set. The relationship of the process to software curricu-
lum models is also addressed, as well as the porting of the

0164-1212/$ - see front matter
2003 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2003.09.024
114 D.J. Bagert, S.A. Mengel / The Journal of Systems and Software 74 (2005) 113120

Table 1
Software Engineering Courses at Texas Tech
Course name Level Required? Prerequisites
Software Engineering (SE) Undergraduate Yes Data Structures
Senior Project Design (SPD) Undergraduate Yes SE, Algorithm Analysis
Senior Project Implementation Laboratory Undergraduate Yes SPD
Software Specication and Design (SS&D) Graduate Yes SE or equivalent
Software Project Management (SPM) Graduate Yes SE or equivalent
Real-Time and Time-Sharing Systems Graduate No SE or equivalent, Systems Programming
Software Quality Assurance and Testing Graduate No SE or equivalent
Web-Based Software Systems Graduate No SE or equivalent
Software Process Improvement Graduate Yes SE or equivalent
Software Construction and Evolution (SC&E) Graduate Yes SS&D, SPM
Software Studio I (SS1) Graduate Yes SS&D, SPM
Software Studio II Graduate Yes SS1

process to the SE courses at the Rose-Hulman Institute of 2.2. Adapting the SEI Tomayko model
Technology. Finally, some plans for a more formal
assessment of the project process is outlined. From 1991 to 1997, the introductory SE course (and
its graduate equivalent) at Texas Tech used the concept
to delivery format using large teams (where each team
2. Background
member has a specic project role, e.g. conguration
manager) in a one-semester course adapted from a
2.1. Software engineering at Texas Tech
model developed by James Tomayko of the SEI (Tom-
ayko, 1987). Then, as now, the intention of the devel-
Table 1 contains the 12 SE courses currently oered at
opment of this process was to have a single, tailorable
Texas Tech. Three undergraduate courses are required
methodology for all SE team projects at Texas Tech.
for the BSCS. Software Engineering is the standard
However, this rst attempt at the development of a
introductory course. This is where the project process is
project had two limitations. First, as a concept-to-
rst introduced to the students. A small project is done
delivery method it needed to be modied in order to
during the second half of the course in order to expose
handle ongoing projects that were developed over sev-
the students to working in a large team (1520 people)
eral semesters or years. Second, the development of the
using a project process. The introductory course is fol-
Tomayko model precluded the invention of the World
lowed by a two-semester senior capstone project Senior
Wide Web, so the materials would need to be adapted in
Project Design and Senior Project Implementation Lab-
order to be eectively used on the Web.
oratory usually with an external (non-university) client.
There are nine SE courses in the Master of Science in
2.3. Other project processes
Software Engineering curriculum. This curriculum was
gradually expanded from three courses in 1989, with the
Where you see processes mentioned in the literature
Masters degree being approved in 1998. A student in
are usually in the context of capstone or process courses.
the MSSE program must take six of those courses, plus
Normally, such processes include what would be ex-
two of the other three, for a total of eight SE courses.
pected, such as planning, requirements, design, imple-
Students must also do a thesis or take four computer
mentation, and software quality assurance. Sometimes,
science courses and pass a written comprehensive exam,
however, they may not include a pointer to the materials
depending on whether they choose a thesis or a non-
actually used in a course. This situation is changing
thesis option, respectively. The undergraduate Software
somewhat with processes being given in textbook format
Engineering courseor its equivalent through work
for educators to use. For example, educators may
experienceis a prerequisite for the beginning-level
make extensive use of Humphreys Personal Software
MSSE graduate courses.
ProcessSM 1 and Team Software ProcessSM (Humphrey,
At the end of the graduate coursework, a two-
1995, 2000) in a SE curriculum. These texts lead students
semester software studio provides a graduate capstone
into understanding how to use their own process for
experience similar to the undergraduate senior project
developing software and then extending that into team
sequence; however, the software studio focuses more on
eorts.
research-oriented projects, and provides more interac-
tion between the project teams. The original inspiration
(and name) for these courses came from the 1990 Soft-
ware Engineering Institute (SEI) graduate curriculum 1 SM
Personal Software Process and Team Software Process are
model (Ardis and Ford, 1989). service marks of Carnegie Mellon University.
 D.J. Bagert, S.A. Mengel / The Journal of Systems and Software 74 (2005) 113120
Another process gaining popularity among educators
is the Unied Software Development Process (Jacobson
et al., 1999) due to its attachment to the Unied Mod-
eling Language. This process takes the developer from
use cases to implementation to testing. Some processes
may be homegrown and available on the web, such as
Real World Lab (RWL) in the College of Computing at
Georgia Tech (http://www.cc.gatech.edu/classes/RWL/
Web). This lab was initially developed by Moore and
Brennan (1995, 1994) and has since undergone evolution
as well with each subsequent instructor. It takes the
developer through planning, requirements, design,
implementation, and testing.
2.4. Need for the process across the curriculum
The use of a particular process is up to the educators
who dene the curriculum. It is of more benet to the
students and educators to have a common process in
every course just simply because of the confusion it
would cause if each educator used a dierent process.
Some courses, however, may not directly involve soft-
ware development and may instead do something else,
such as a tutorial or experimental study. A process
across the curriculum should incorporate the ability to
do such things.
3. The Project Process
3.1. Introduction to the process
The Project Process supports several roles in a pro-
ject: software manager, conguration manager, sub-
contract manager, requirements analyst, designer,
programmer, software quality assurance analyst, trai-
ner, and study analyst. It has document templates for
weekly reporting of work, reviewing documents,
assessing team member performance, plans, require-
ments, design, software manuals, training materials,
studies, and web pages. It supports cooperating
instructors indierent courses working together on a
development or other type of project through the use of
subcontracts and subcontract managers (Mengel and
Carter, 1999). It allows the inclusion of expert mentors
to guide students in their projects and clients who would
like software development work done. It also discusses
team responsibilities, the team grievance process, pro-
fessionalism, and grading.
The content of the document templates are as
streamlined as possible so that students do not have to
get too bogged down in documentation and give as
much guidance as possible so that students do not have
to wonder about what goes into a document. All doc-
uments normally require a revision history and a To
115
Do List for what is outstanding before the document is
complete. For example, the requirements document fo-
cuses the student on the users environment, the
requirements needed based upon the IEEE Require-
ments Specications Standard (IEEE Recommended
Practice for Software Requirements Specications,
1998), client materials, a to do list, a reference list, and a
revision history. Due consideration was given to the rest
of the IEEE Standards, but they can be quite large; i.e.,
more than what students can handle in one or two
semesters. As an additional example, the design docu-
ment contains sections on the approach, similar work,
architecture, user interface, external interfaces, data,
detailed design, and cross-referencing to the require-
ments.
3.2. Evolution of the process and document set
The Project Process was rst developed in the fall of
1998 and was initially based upon Georgia Techs Real
World Lab. At that time, the authors were not able to
nd materials from other sources and it seemed a good
idea to build o of a successful course. It was also
decided to follow the RWL paradigm and post materials
to the Web. This seemed to be the most economical and
ecient way to allow all stakeholders viewing privileges
of the projects and Project Process.
Initially, the document templates were fairly
unstructured (which was like the RWL) but certainly
not without guidance to allow students some freedom.
However, it was discovered rather rapidly that students
would make use of their freedom in ways that are
counterproductive to getting projects done, such as
spending an inordinate amount of time on formatting
instead of solving the problem. The document template
set, therefore, underwent changes to provide more
structure and focus on problem solving. In addition,
templates were added to support user analysis studies,
subcontracts to work with other courses, and studies to
perform experiments. Further, unlike RWL, the Texas
Tech process was developed with an entire curriculum in
mind.
Students played a large part in the evolution of the
Project Process both through observation of their
behavior with the Project Process and from their com-
ments about the Project Process. When the Project
Process was rst introduced to the undergraduate SE
course and for a few iterations of the Project Process
afterward, students did not care for the amount of
documentation that seemed to detract from the pro-
gramming of the software. On the other hand, for
example, the requirements team would become frus-
trated if the design or programming teams deviated
from the published requirements and produced some-
thing the client did not specify. In any event it slowly
became clear throughout the semester to the students
116 D.J. Bagert, S.A. Mengel / The Journal of Systems and Software 74 (2005) 113120
that the documents and programming were needed to
accomplish the project successfully to the clients satis-
faction. In observing the students, if they continually
seemed to have diculty on particular document sec-
tions, those sections were eliminated, changed to an-
other document where they made more sense, or given
more guidance in the document template. Students
would also comment on various sections leading to the
improvement and shortening of the document tem-
plates. Indeed, some students have improved the docu-
ment templates on their own by utilizing better ways of
expressing detailed design. For example, one student
decided that use cases would be extremely good at
modeling detailed design. The design document pro-
duced was extremely readable and accessible to the
programming team.
The current version of the TTU Project Process can
be found at http://ednet.coe.ttu.edu/proj/ and includes
links to past versions. The document templates in the
Project Process are too large to include in this paper, but
are publicly available to those wishing to use them as is
or in modied form while referencing the original Pro-
ject Process.
3.3. Software projects developed
Several projects developed with the Project Process
have reached successful fruition and have been deployed
(Bagert et al., 2002). Several of these successful projects
have been for on-campus (internal) clients, who seem
to be the easiest to use since they are usually very eager
to get their software developed and do not usually leave
the university suddenly as industrial clients may. Some
industrially sponsored projects have failed because the
one industry contact left the company or the company
was sold to another. Three examples on-campus projects
that have either been developed or are in ongoing
development are:
E-COACH (Gregory et al., 2002). This tool can be
used to determine whether a student interested in
engineering would be well-suited to the eld, provides
information on the persons learning styles, helps stu-
dents understand how to get enough sleep to be eec-
tive in learning, and helps students select courses in
their degree programs.
Mock FE (Heinze et al., 2002). This tool enables
engineering students who take the Mock Fundamen-
tals of Engineering Examination to get their results
on-line and to plot historical trends of the results.
QUICK Schedule (Owen et al., 2000). This tool auto-
mates course scheduling; a student states what
courses are desired and what time slots cannot be
used for taking classes, and QUICK provides a trial
schedule, using the universitys current list of open
class sections. QUICK will be moving from student
development to full use by Texas Tech University
as part of the students registration process.
O-campus (external) clients have provided a wide-
range of potential projects, including:
The development of a software tool to track project
activities within a software organization for
CMMISM 2 assessment purposes.
Enhancement of a software tools object-oriented de-
sign and code generation features.
Porting an existing web application from a Windows
to a Macintosh platform.
3.4. Use of the process in dierent courses
3.4.1. Capstone courses
The two-semester Senior Project sequence uses a
tailored and extended project process in order to include
the following:
Document and code inspections, as opposed to the
reviews used in the standard process.
Some additional detail given to software testing by
the project team.
More focus on grading the project artifacts both
within the weekly reviews and after they are posted
and under conguration control.
Several weeks are provided for acceptance testing by
the client, which allows for a short maintenance cycle
not (easily) possible in a one-semester course.
The software studio sequence also takes advantage of
the extended timeframe in order to have more accep-
tance testing and some maintenance. However, the re-
views from the standard process are used instead of
inspections in order to take advantage of the interaction
between the project teams during their time together in
the studio setting.
3.4.2. Examples from other courses
The Software Engineering undergraduate course en-
ables students to focus on the basics of planning,
requirements, design, implementation, training, and
software quality assurance. Other parts of the Project
Process are not used. These students work with an on-
campus client and either continue with a previous pro-
ject or start a new one.
The Software Specication and Design course focuses
on the use of modeling techniques for specication
purposes, how to accomplish architectural design, and
how to ow into detailed design. This class may write a
training tutorial on a certain part of specication and/or
design and also use the Project Process document tem-
2
CMMISM is a service mark of Carnegie Mellon University.
 D.J. Bagert, S.A. Mengel / The Journal of Systems and Software 74 (2005) 113120
plates for requirements and design. They may also do a
study on comparing various requirements or design
techniques.
The Software Project Management courses looks at
the scheduling, budgeting, and management of a devel-
opment project. The students in this course focus upon
the planning documents in the Project Process and may
do a training tutorial on how to manage a project from
beginning to end. The students also take on various
management roles during a project to gain some expe-
rience in leading other team members to successful or
sometimes not so successful project work.
The Software Construction and Evolution course
allows for assignments which focus on the post-design
end of the Project Process, including implementation,
detailed testing, code inspections, and creating more
than one increment of the software (i.e., an example of
software evolution).
In the Software Process Improvement class, the pro-
ject process used in the other SE courses plays a dierent
role. In this course, dierent project model frameworks
such CMMR 3 and ISO 9001 for Software are used to
discuss process-based SE, and the denition, assessment
and improvement of the process using it. In this context,
the project process for the Texas Tech SE courses can
frequently be used in various examples. In some
semesters, students have been divided into teams in
order to assess the Project Process against one or more
of the widely used models.
4. Benets of the process
The objective of the Project Process is to provide a
process which could be used throughout both under-
graduate and graduate curricula for both eective pro-
ject development and providing the student with a
greater understanding of the software process. A set of
expected outcomes is formulated, but a rigorous
assessment plan has not been initially formulated.
About a year after the initiation of the project process,
the outcomes were informally evaluated, with a sum-
mary of the evaluation results below.
Increased communication between stakeholders.
Greatly improved communication was immediately
realized by both the client and the course instructor,
and continues to the present time. Also, the degree
of teamwork within the student project teams (and
their reviewers) has gradually improved.
Platform independence for viewing the Project Process
and most of the artifacts. The Web/HTML format has
meant that project information can be accessed from
3
CMMR is registered in the US Patent and Trademark Oce.
117
virtually any type of computer on the Internet. Also,
if the application being developed is web-based, this
accessibility extends to the product itself.
More eective monitoring by the instructor of student
progress and the timeliness of submissions. Monitoring
the submission or updating of project artifacts
through the project web page has been very eective,
and has also made checking the actual times of sub-
missions simple.
The ability to handle larger-scale projects. The use of
an incremental software development model has
meant that projects can proceed at various stages
over several semesters. For instance, the QUICK
Schedule project has been in operation at Texas Tech
for over three years (http://ednet.coe.ttu.edu/quick)
and is under maintenance and enhancement during
its fth year of existence. The only negative aspect
to the longer projects is that there are more potential
projects than there are students available to develop
them!
Better-documented and more reliable products. The
web format makes it much easier to submit, locate
and review project artifacts. The improved documen-
tation and review process has in turn led to better
functionality in the nal product.
Eecting tailoring of a single process for all software
projects. The online accessibility of the process has al-
lowed it to be used in a variety of courses. However, a
method for easily documenting a particular tailoring
of the process is still needed.
Increased motivation among stakeholders. Students
are very appreciative of the templates which make
their work clearer and as mentioned before, everyone
has the opportunity to monitor progress making
everyone more willing to participate.
The subsequent development of a formal outcomes
assessment model is discussed in Section 7.
In commenting about the current version of the
Project Process, students are very appreciative of the
document templates. They still do not necessarily like to
write all of the documentation, but they understand why
the document templates are structured as they are. In
addition, student teams are having more success in using
the Project Process and the quality of the project work
has risen over the semesters the Project Process has been
used. For example, a software project could remain in
development for two or more years during the early use
of the Project Process and now project completion is
seen in as little as one or two years.
5. Relationship to curriculum models
Having a exible, changeable project process
throughout a SE sequence is important because virtually
118 D.J. Bagert, S.A. Mengel / The Journal of Systems and Software 74 (2005) 113120
every course in such a sequence is likely to have a project
which can take advantage it. For instance, the afore-
mentioned SEI graduate curriculum model (Ardis and
Ford, 1989) recommended six required core courses,
covering requirements, design, construction and main-
tenance, V&V, project management, and formal meth-
ods. These courses all have assignments that can use the
project process. The model also contains a capstone
software studio.
The Guidelines for Software Engineering Education, a
product of the Working Group for Software Engineer-
ing Education and released in 1999 as an SEI Technical
Report (Bagert et al., 1999), has been the de facto source
for an undergraduate curriculum model in recent years.
Once again, all of the eight SE courses recommended in
the Guidelines SE curriculum (except for a one-hour
rst year seminar and a Professionalism and Ethics
course) are likely to be implemented as having projects
as a component.
A joint IEEE-CS/ACM committee is developing
Computing CurriculaSoftware Engineering (CCSE),
which is part of the IEEE-CS/ACM Computing Curric-
ula project. The CCSE committee is developing recom-
mendations for undergraduate SE education and
curricula. As of this writing, the primary product of
CCSE has been the second public draft of Software
Engineering Education Knowledge (SEEK), which can
be found at http://sites.computer.org/ccse. This draft
contains 10 Software Engineering Knowledge Areas
(KAs), generally reecting topics that have been seen in
the undergraduate and graduate models listed above.
Several units and topics (the two levels of subareas for
each knowledge area) of the Process KA directly reect
topics covered through learning and using the Project
Process at Texas Tech, including process denition,
process infrastructure, and process tailoring.
6. Porting the Processan example and lessons learned
In mid-2002, a project was undertaken to port the
Texas Tech Project Process to the Rose-Hulman Insti-
tute of Technology (RHIT), coinciding with the change
of aliation of one of the authors (Dr. Bagert) to that
school. Rose-Hulman is on the quarter system of study
(with 10-week terms), but almost all of its courses have
virtually the same number of contact hours as a
three-credit semester course in the US. The BSCS at
Rose-Hulman currently contains four SE coursesa
two-course introductory sequence in the winter and
spring (second and third) terms of the junior (third)
year, followed by a two-term capstone project sequence
in the fall and winter (rst and second) terms of the
senior (fourth) year. It was decided, therefore, to begin
implementation of the web-based Project Process with
the rst course available, which was the rst half of the
senior project. Two dierent faculty members (including
Dr. Bagert) were each supervising some of the project
teams. The process was later tailored for the SE intro-
ductory sequence.
The SE courses at Rose-Hulman are a good test for
the project process, since traditionally the team sizes are
small (65), with an agile/prototyping model used for
software development (as opposed to the more tradi-
tional methods commonly employed at Texas Tech).
This, and the fact that the process previously used for
senior projects at RHIT was less document-intensive
and not as structured overall, meant that the process
and its templates met some initial resistance, despite the
fact that it had already been tailored somewhat from the
Texas Tech version before being posted on the Web and
introduced to the students. The initial diculties, how-
ever, were addressed through individual students inter-
acting with the instructor and through discussions
during team meetings with their project supervisor. The
process was then subsequently used in the two-term
introductory sequence and more maintenance and
enhancement projects in a special topics course in soft-
ware construction and evolution, with more exibility
allowed in both courses in modifying the style (but not
content) of the templates than has been done to date at
Texas Tech. By the end of the 20022003 academic year,
there had been signicant progress made in the accep-
tance and eective use of the process.
It is interesting to compare the work done using the
Project Process to date by senior project students at
Rose-Hulman as opposed to their counterparts at Texas
Tech. At TTU, senior project students have already used
the process at least once before, and are therefore
somewhat more procient in its use. A new Bachelor of
Science in Software Engineering (BSSE) at Rose-Hul-
man has been approved to begin in the 20032004 aca-
demic year. This degree will have nine required SE
courses, so that in future years, students taking the
capstone course should be well-versed in the process.
Before the 20032004 year begins, SE faculty will rst
meet to revise the process in order to both incorporate
lessons learned, and insure that the process can be most
eectively used in the new BSSE curriculum.
The RHIT process is located at http://www.cs.rose-
hulman.edu/curriculum/project_process.html.
Porting the Project Process to RHIT was a little
easier than it might be for most interested parties since
one of the authors was involved. Utilizing a process
when one has never done so or when one is trying gure
out the process so it can be ported to his/her institution
is not easy. A process is going to be large and have a
learning curve associated with it. In addition, it may also
seem unreasonable to spend the time monitoring and
grading the students to ensure they are practicing the
process correctlyindeed, a process is only as good as it
is practiced. Students do not necessarily have to have a
 D.J. Bagert, S.A. Mengel / The Journal of Systems and Software 74 (2005) 113120 119

good experience with process, but they should under-
stand why they had a bad experience so they can per-
form better with process next time. Sometimes students
who have had a bad process experience understand how
it can go wrong better and can avoid problems during
the next project.
As was mentioned, monitoring the students during
the process and grading the project materials may seem
to take an unreasonable amount of time. One of the
positive aspects to all of the time spent is that it does get
easier and the quality of the students software increases
as the instructor gets better at teaching and monitoring
the process. Nothing is more gratifying than watching
students improve in their ability to tackle ill-structured
problems, to work eectively in teams, and to produce
high quality software. It is very dicult to do this
without process in the authors experience.
7. Formal assessment of the process
A formal outcomes assessment model for the project
process has been developed at Rose-Hulman for imple-
mentation at both RHIT and Texas Tech during the
20032004 academic year. The Oce of Assessment at
Rose-Hulman is well known, and for the last ve years
has hosted Best Assessment Processes, an annual sym-
posium with speakers and attendees from several coun-
tries. The assessment model for the Project Process
includes an assessment of the various stakeholders using
archival data, surveys, and interviews. An assessment
matrix that summarizes this plan can be found in Table 2.
8. Conclusions and future directions
In order to facilitate the study of software process,
which is essential to the education of future software
professionals, a standard, tailorable, and web-based
process was developed at Texas Tech University for use
in its 12 undergraduate and graduate SE courses. All
project artifacts using this process are posted to the
course web page, which enhances communication be-
tween team members (including distance education
students) and between the project team and their client.
This process has received positive feedback from all
stakeholders. Recently, the process has been ported to
another institution (Rose-Hulman) with a dierent
framework for its SE courses; this will allow for a
comparison and facilitate greater understanding of the
process model.
A more formal assessment of the project process is
planned for 20032004. In future years, it is hoped that
data can be collected on the use of the project process in
for a variety of application domain areas, although this
likely will require its use at more schools in order to

Table 2
Assessment matrix
Assessment question Group to be Assessment Method Timeline Comments
Assessed
To what extent has the web-based Students at Texas Course Surveys Past ve years Course survey items that provide
project process enhanced student Tech insight into students perspectives of
learning? Students at TTU Surveys Currently enrolled learning
and RHIT students or Fall
2003
What has been the cost/benet Faculty at Texas Interviews Summer 2003 Interview faculty on enhancement of
factor of using a standard Tech (and RHIT) student learning before and after using
tailored project process as the project process. Also, obtain faculty
opposed to various processes insight into benets of a standard
per course across the model as opposed to various models
curriculum? used per course across the curriculum
To what extent has the web-based Students at TTU Surveys and Fall 2003 and Peer review assessments for observing
project process enhanced and RHIT Teaming Skills Spring 2004 students teaming skills should provide
students teaming skills? Observations insight into students demonstration of
Faculty at Texas Interviews Summer 2003 eective teaming skills
Tech (and RHIT)
To what extent has the web-based Students Surveys Fall 2003 and Surveys, observations, and interviews
project process enhanced Spring 2004 with students, faculty and clients will
communication between project provide insight into students
teams and clients? Communication Fall 2003 and communication skills with regard to the
skills observations Spring 2004 project process
with clients
Faculty Interviews Summer 2003 and
Summer 2004
Clients Interviews/Surveys Summer 2003 and
on Communication Summer 2004
analysis
120 D.J. Bagert, S.A. Mengel / The Journal of Systems and Software 74 (2005) 113120
obtain the breadth of applications needed to compile
meaningful data.
In general, the Project Process is a living artifact and
will continue to change as data on its eectiveness is
collected, and as automated tools become available that
can be taught without distracting the students from the
important concepts of a course, due to the long learning
curve. For instance, the undergraduate SE course at
Texas Tech may only be able to incorporate a few
automated tools, such as planning and tracking, but later
courses can begin to use more complex tools for design
modeling and testing. There is some benet in teaching
SE without the noise of automation; it can focus stu-
dents more on practicing the concepts rather than
learning the tools. Eventually, students who are pro-
cient at practicing the concepts should learn the tools to
make their job easier and faster. A short-term improve-
ment is to have a guidance matrix for customizing the
process to a particular course, which would show the
course examples used in the SE courses at Texas Tech as
well as other plausible scenarios for use of the process.
Acknowledgements
The authors wish to thank Gwen Lee-Thomas,
Director of Assessment at the Rose-Hulman Institute of
Technology, for her eorts in formulating an assessment
plan for the project process, including the assessment
matrix shown in Table 2. In addition, the authors wish
to thank all of the instructors, clients, and students who
have helped to improve the Project Process and make it
more eective.
References
Ardis, M.A., Ford, G.A., 1989. SEI Report on Graduate Software
Engineering Education, Technical Report CMU/SEI-89-TR-2,
Carnegie Mellon University, Pittsburgh, PA, 1989.
Bagert, D., Hilburn, T., Hislop, G., Lutz, M., McCracken, M.,
Mengel, S., 1999. Guidelines for software engineering education,
Version 1.0. Technical Report CMU/SEI-99-TR-032, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA,
October 1999.
Bagert, D.J., Gregory, J.M., Mengel, S.A., Heinze, L.R., 2002.
Engineering Education Innovation With Software Engineering
Projects. Frontiers in Education. Available from <http://e.eng-
rng.pitt.edu/e2002/papers/1475.pdf.>.
Gregory, J.M., Heinze, L.R., Bagert, D.J., Mengel, S.A., 2002.
ECOACH: a paradigm shift for ecient advising. Frontiers in
Education. Available from <http://e.engrng.pitt.edu/e2002/pa-
pers/1263.pdf.>.
Heinze, L.R., Gregory, J.M., Bagert, D.J., 2002. Web-based auto-
mated assessment for Abet programs. Frontiers in Education.
Available from <http://e.engrng.pitt.edu/e2002/papers/
1308.pdf.>.
Humphrey, W.S., 1995. A Discipline for Software Engineering.
Addison-Wesley, Reading, MA.
Humphrey, W.S., 2000. Introduction to the Team Software Process.
Addison-Wesley, Reading, MA.
IEEE Recommended Practice for Software Requirements Specica-
tions, 1998. IEEE Std. 8301998. IEEE, New York, NY.
Jacobson, I., Booch, G., Rumbaugh, J., 1999. The Unied Software
Development Process. Addison-Wesley, Reading, MA.
Mengel, S.A., Carter, L., 1999. Multidisciplinary education through
software engineering. Frontiers in Education. Available from
<http://e.engrng.pitt.edu/e99/papers/1390.pdf.>.
Moore, M., Brennan, T., 1995. Process improvement in the classroom.
In: Ibrahim, R.L. (Ed.), Proceedings of Eighth Conference on
Software Engineering Education. Springer-Verlag, New York, NY,
pp. 123130.
Moore, M., Potts, C., 1994. Learning by doing: goals and experiences
of two software engineering project courses. In: Diaz-Herrera, J.L.
(Ed.), Proceedings of Seventh Conference on Software Engineering
Education. Springer-Verlag, New York, NY, pp. 151164.
Owen, C., Bagert, D., Gregory, J.M., 2000. QUICK: using web
technology to facilitate class scheduling. In: Proceedings of the
American Society for Engineering Education Gulf-Southwest
Section Annual Conference, Las Cruces, NM, 58 April 2000,
13p (CD-ROM).
Tomayko, J.E., 1987. Teaching a project-intensive introduction to
software engineering. Technical Report SEI-SR-87-1, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, PA,
1987.
Donald J. Bagert is a Professor of Computer Science and Software
Engineering at the Rose-Hulman institute of Technology, where he
also has the title of Director of software Engineering. Don came to
Rose-Hulman in August 2002 after 14 years at Texas Tech University.
His current research interests include software process improvement,
software tools for student advising, and software methodologies. He
received a Ph.D. in Computer Science from Texas A&M university in
1986. He is the steering committee chair for the IEEE-CS Conference
on Software Engineering Education and Training, and the Managing
Editor of FASE, an electronic newsletter devoted to software engi-
neering education, training and professional issues, in 1999, he co-
authored the Guidelines for Software Engineering Education, which
quickly became the de facto worldwide standard for undergraduate
software engineering curriculum. He is the rst person licensed Pro-
fessional Engineer in software engineering in both Texas and the
united States. Don is a member of the Working Group on Software
Engineering Education and Training, as well as the Software Engi-
neering Program Leaders Association. He is also the chairperson of the
CSDP (Certied Software Development Program) Certication com-
mittee, a member of both the Educational Activities Board and the
Professional Practices Committee for the IEEE Computer Society, and
is a Senior Member of the IEEE.
Susan A. Mengel is currently an associate professor in the Computer
Science Department at Texas Tech university and oversees the Mas-
ters in Software Engineering program. Her research areas include data
mining and Web caching. She developed a software process for stu-
dents to use in the undergraduate and graduate software engineering
courses in addition to web and database servers for student develop-
ment use. She has participated in NASA and US Army summer
research programs and is funded by NSF, USDA, and Texas Coor-
dinating grants. She currently serves on the IEEE-CS Board of
Governors as well as the Conference and Tutorials Board, the Audit
Committee, and the Web Operations Committee, she has served on
the IEEE-CS Educational Activities Board where she worked on the
Computing Curriculum eort for both the Computer Science and the
Software Engineering volumes.