895 subscribers
Note: If you have problems with the format of this document,
try
<http://www.cs.ttu.edu/fase/v10n01.txt>
An HTML version of this issue is available at
<http://www.cs.ttu.edu/fase/v10n01.html>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Table of Contents
Letter From the FASE Archivist: Solving
the V10 Bug
This Month's Topic:
Coping with the Faculty Shortage
Last Month's Topic:
Addendum
Next Month's Topic:
Top Ten Contributions - Don't Forget to Vote!
Call
for Guest Editors and Topic Suggestions
News Items
IEEE Software
Roundtable: Best Influences on SE
IEEE
Software Letters to the Editor on Professional SE
Undergraduate
Software Engineering at Butler University
Calls for Participation
IEEE-CS
State-of-the-Practice Survey
Conference Announcements
CSEE&T
2000 Final Program
Position Openings
Florida
State University
University
of Nebraska-Lincoln (tenure-track positions)
University
of Nebraska-Lincoln (chair position)
Contact
and General Information about FASE
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Don Bagert (FASE Archivist)
Letter From the FASE Archivist: Solving the V10 Bug
Since I know all of you are tired of hearing about
the Y2K bug,
here is an interesting little problem concerning the FASE ftp archive,
which is at
ftp://www.cs.ttu.edu/fase/archive/
Now that FASE is entering its tenth year of publication, in order
to
get Volume 10 (or V10) after Volumes 1-9 9, the first part of the
prefix for all of the single-digit volumes have been changed in
the
ftp archive to have a leading zero in the volume. So, v1n01.txt
became v09n01.txt, and so forth. In that matter, the lexicographic
order of the files in the ftp listing is the same as the chronological
order. As far the Web archive, accessible from
goes, both old and new filenames will be used. So, either
http://www.cs.ttu.edu/fase/v1n01.txt
and
http://www.cs.ttu.edu/fase/v01n01.txt
will access Volume 1, Number 1 of FASE.
So...the V10 is problem solved, and for about $250
billion dollars
less than the USA spent on Y2K bug! (Of course, the problem
is only
solved until Volume 100, Number 1 comes out in January 2090, but
that
will be someone else's problem =)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This Month's Topic: Coping with the Faculty Shortage
Topic Editor: Don Bagert, Texas Tech University
Don.Bagert@ttu.edu
Several distinguished leaders in software engineering were given
the
following topic description:
"As work of the IEEE-CS/ACM Software Engineering Coordinating
Committee (SWECC) and its related groups progress, attention is
increasingly shifting to implementation. A major roadblock
to the
implementation of software engineering degree programs is the lack
of qualified full-time faculty. This issue will focus on
the problem,
and suggest solutions."
Contributions are enclosed from:
James H. Cross II
Chair of Computer Science and Engineering
Auburn University
Peter B. Henderson, Head
Department of Computer Science
Butler University
Joseph Kasser (with two articles!)
Adjunct Associate Professor
University of South Australia
Kenneth L. Modesitt
Professor and Chair
and
Bruce R. Maxim
Associate Professor
Department of Computer and Information Science
University of Michigan-Dearborn
Mark Sebern
Program Director, Software Engineering
EECS Department
Milwaukee School of Engineering
Rayford B. Vaughn, Jr.
Associate Professor of Computer Science
Mississippi State University
I'll share my own viewpoint at the end of this document.
######################################################################
Viewpoint - Coping with the Faculty Shortage
James H. Cross II
Chair of Computer Science and Engineering
Auburn University
In the spectrum of computing disciplines, I think of software
engineering (SwE) fits nicely between computer science (CS) and
computer engineering (CpE), although it is more tightly coupled
with
CS, at least for the foreseeable future. Since there is clearly
a
faculty shortage in CS, and SwE is essentially a subset of CS at
the
PhD level, the faculty shortage in SwE is at least as great as
for
CS.
Obviously, there is no easy solution to our faculty shortage in
SwE.
It might be useful to describe the ideal candidate in today's terms:
(1) Ph.D. in CS with specialization in SwE, (2) master's degree
in
SwE, and (3) experience on large software projects. The last
item
should be somewhat controversial, since no other engineering
discipline requires faculty to have industrial experience.
Over the
next few years, faculty in CS and computer engineering (CpE) will
migrate to SwE programs if this is where their interests are and
the
opportunity is available.
Our current best hope for SwE undergraduate programs is to couple
them
with CS programs. SwE topics are prevalent in many undergraduate
textbooks beginning with CS 1 and 2 (e.g., object-oriented design
and
programming). As a result, many CS faculty are becoming more
comfortable with the notion of SwE. Those CS faculty with
an interest
in the traditional SwE topics (e.g., testing) will hopefully migrate
to our advanced SwE courses.
--jc--
----------------------------------------------------------------------
James H. Cross II, Ph.D., Professor and Chair, Computer Science
and
Software Engineering, 107 Dunstan Hall, Auburn University, Auburn,
AL
36849-5347, 334-844-6315 (Voice), 334-844-6329 (FAX),
cross@eng.auburn.edu
######################################################################
"Is there a software engineering faculty shortage?
Viewpoint"
Peter B. Henderson, Butler University
Does anyone have data on how many software engineering PhD graduates
there are per year? How many software engineering faculty
positions
are to be filled each? Compare these two numbers to get your
answer.
Unfortunately it is not that simple. The specifications are
not
precise. Who is a SE graduate? What is a SE faculty
position? What
about current faculty who switch from/to SE, or leave academia
for
industry, or move from industry to academia? And other undefined
parameters.
If you are a CS department, hiring faculty with a practical
inclination is hard. Advertising for and actually hiring
one
qualified software engineering faculty member is near impossible.
The odds may increase in your favor if you have a software engineering
program. Birds of a feather flock together.
A solution to this shortage is simple, but impractical. Get
industry(academia) to pay software engineers less(more)
respectively. Graduating more software engineers(if
possible)
primarily fuels industry. Academia needs carrots to attract
qualified
software professionals. These could be more money(like business
schools), unique academic programs leading to unique opportunities,
or
faculty coop programs mixing academic with industrial positions.
Another potential solution is a two tier approach. Traditionally
engineering faculty teach more upper division/graduate courses
than
CS faculty. Attrition of CS faculty is a reaction to large
teaching
loads, primarily lower division courses. Seek creative ways
to better
insulate SE faculty from overloaded lower division courses.
A better solution is to make software engineering a true professional
engineering discipline. Luckily the trends are in this direction,
abet slowly (see footnote). Curricula focusing on rigorous,
disciplined approaches to software development coupled with an
apprenticeship employment model and licensing of software
professionals, as in other engineering disciplines, is required.
As
a professional discipline, more qualified software engineers would
be
attracted to academia. As a corollary, fewer unqualified students
would be attracted to such programs.
Footnote: Did you catch the pun? ABET - Accreditation Board
for
Engineering Technology
######################################################################
Teaming for Teaching: Issues on Instructors and Institutions
Dr. Joseph Kasser (joseph.kasser@unisa.edu.au)
University of South Australia
http://www.umuc.edu/~jkasser
Abstract
As we enter the 21st century, the demands for competent technological
personnel are greater than ever. Universities wishing to meet this
growing demand for education in systems and software engineering
are
facing a scarcity of qualified seasoned systems and software engineers
who can teach the topic. This gap between the need and the capability
to train personnel is not an easy one to fill. This paper speculates
as to how a slight change in the relationship between instructors
and
institutions could affect the teaching of systems and software
engineering.
Introduction
The gap between the need and the capability of the personnel is
not an
easy one to fill. Universities wishing to meet this growing demand
for
education in systems and software engineering are facing a scarcity
of
qualified seasoned systems and software engineers who can teach
the
topic. Consequently the instruction provided to students may not
be
at the level program directors and students desire. Consider how
a
slight change in the relationship between instructors and institutions
could affect the teaching of systems and software engineering.
Background
Historically, universities have been repositories of knowledge and
places to which students are attracted in order to acquire knowledge
from the renowned academics. The university provides the
infrastructure for the academic instructor to teach the graduate
semester in software engineering. The infrastructure is not limited
to the classroom and administrative functions; it also includes
research facilities and technical libraries. The World Wide Web
has,
for the first time, made possible a significant change to that
paradigm. Students and instructors can now attend a university
without
physically being present on campus.
Recognition that distance education technology applies to instructors
as well as to students allows the universities to attempt to alleviate
the shortage of qualified instructors by augmenting their local
staff
and using suitable persons located outside their geographical areas
in
staffing the classes taught via distance education. For example,
the
Information and Telecommunications (ITS) Department at the Graduate
School of Management and Technology (GSMT) at University of Maryland
University College (UMUC) runs or has run on-line classes in software
engineering subjects that are taught by adjunct faculty in Japan
and
Australia.
Graduate seminar courses in software engineering at the GSMT are
delivered in the hybrid constructivist and objectivist formats
using
lectures, required readings, and student projects. These seminars
have
traditionally been developed around textbooks and journal articles.
In
the last few years, web published articles have also been used
as text
materials. When a course is developed around the textbooks and
associated reading materials, the value added by the university
is in
the format and structure of the course and in the persona of the
instructor. In the ITS Department, these seminar courses are initially
developed by the Program Director or by an adjunct professor as
"works
for hire". If an adjunct professor develops a course, the adjunct
professor normally goes on to teach the course in the program.
Staff
or adjunct personnel also teach other existing courses. It is the
instructor who embellishes the lectures and discussions with
anecdotes based on experience and other source materials not on
the
list of student required readings. Because it is the instructor
who
embellishes the course materials and makes them come alive to the
students, each class, as taught, is slightly different.
An alternative paradigm
Before reading the next section, note that universities are already
purchasing courses that they do not have the resources to produce
on
their own. Consider the effect of changing the relationship between
the university and instructor from that of employer - employee
to that
of customer - contractor.
Imagine a university with no full-time teaching faculty! Instead,
the
universities meet the need for instructors by issuing tenders for
subject matter experts to create, teach and maintain complete courses
in the systems and software-engineering curriculum.
The universities publish requests for proposals (RFP) for course
material useable both in the classroom and via distance education
on
web sites and electronic journals such as the one you are reading.
The RFP could also contain the Web URLs of the templates and standards
for formatting the course material. The required material would
comprise course materials, lecture notes, and even PowerPoint
transparencies with audio accompaniment on a topic. Responses to
the
RFP could come from various places including:
* The research faculty at the institution.
* Research faculty at another institution.
* Another teaching university.
* Practitioners in industry; the traditional adjunct professors.
* A Company that provides training in software engineering.
* Subject matter experts who can't or don't have the time to teach,
teaming with teachers who have some knowledge of the subject.
The university would evaluate the offers based on whatever criteria
the institution chooses to use. These criteria could include:
* reputation of the instructor,
* publications in the field,
* student evaluations,
* teaching experience,
* cost of course,
* delivery mechanism,
* quality of materials,
* the frequency of upgrades in a multi-semester course.
* degree of currency of reading material, and
* other.
The competition would encourage the instructors to keep the material
current. The institution could choose to tender for a single course,
or the same course to be provided several times in several years.
At
this level there is no difference between this paradigm and the
current situation as far as the students are concerned. However,
the
effect of this change could serve another purpose.
The instructor's perspective
Now look at the situation from the perspective of the instructor.
The
fee paid by the institution for producing and teaching one new
course
does not in general cover the costs to produce the course, teach
it,
and grade student work at a reasonable hourly rate. Currently,
adjunct
instructors primarily teach for reasons other than money. These
reasons include the:
* Desire to be associated with the university, either for the glamour
or for the library resources.
* Desire to pass on their knowledge and experiences to the next
generation of systems and software engineers.
* Thought of transitioning from industry to academia in the future
and
the consequent need to build up teaching experience.
Yet academia in most universities is much more than teaching, and
the
skills and expertise developed by a career in industry are the
factors
that make a person a desirable teacher, but not necessarily a
desirable full-time member of the faculty. People who wish to transfer
from industry to academia may not have the:
* Research skills needed in the traditional university.
* Administrative skills needed to deal with students outside the
classroom in the role of a help desk operator providing
advice and
slicing away at red tape to facilitate the education of
the student.
These skills are a requirement in a teaching university
like UMUC.
Could this new paradigm provide these adjuncts with their desired
career transfer in a way that does not bring them into the traditional
full-time academic positions? If the financial rewards were
worthwhile, it might. So read on.
What would happen if instructors could tender courses on a
non-exclusive basis? Non-exclusive courses mean that the instructor
is allowed to teach the course at more than one institution via
distance delivery or by short intensive courses lasting a week.
There is no intention to allow an instructor to deliver the same
course in the classroom in different universities in the same
geographical area. If instructors could teach the same course for
more than one university, the potential number of students increase
and so does the financial reward.
In this situation, each institution offers the class and the
instructor delivers it on behalf of the university. However, this
is
still the traditional paradigm in which the students come to the
universities.
What if, instead of the instructors subcontracting to the
universities, the universities come to the following agreement
with
the instructors? The instructors offer the courses and the
universities administer the enrollment of the students in the class
and pay the instructor on a per student basis. In this scenario
there
may be students from several universities taking the same class,
working in teams together as if they were all in the same school,
yet
the instructor would file grade reports to the several institutions
at
the end of the semester! Too far fetched for you? Well, for your
information, a Division of a major US Defense Contractor in the
Washington DC Metro area has developed three graduate level face
to
face classes in systems engineering and telecommunications for
its
internal leadership development program. Each of the classes is
accredited with four major universities. Employees in the contractor's
program seek admission to one of the universities to pursue a graduate
degree. They take the regular university's classes, as well as
the
three classes mentioned above. When the in-house class runs, the
administrator has to report the student grades to the specific
university in which the student is enrolled. That means grade
reports can go out to up to four universities. In the distance
education environment, the students could be located anywhere on
or
near the planet as long as they have an Internet connection.
This scenario also has an impact on subjects that are taught
infrequently at any single institution due to the lack of student
demand and the financial loss of staffing a class attended by few
students. In such a situation the student has to:
* Forgo the class - the student looses.
* Wait until the class is offered - the student may or may not
be able
to work out a schedule of classes to accommodate the delay.
* Take the class at another institution and transfer in the credits
-
the university loses the tuition payments.
Experts in the field could increase their income from teaching a
class
each semester by filling it with students from several institutions.
This is a win-win-win scenario in that:
* The instructor benefits by the greater earnings from teaching.
* The student benefits by the availability of the class when the
student needs it.
* The institution benefits by collecting the tuition because the
class
is not transferred in.
Common to all threads in this scenario is the global experience
gained
by the student in working with other students across institutions.
Multiple awards
Now speculate a little further. What if, instead of the RFP being
for
a single award, the university made multiple awards in the manner
of
a United States Government multiple-award task-ordered contract.
When
an institution received several offers that met its requirements,
it
could award the opportunity to provide the course to all qualified
offerers and the students could take the class with their instructor
of choice. For example, the university would announce that for
2001,
any one of the classes in systems engineering offered by a list
of
approved instructors would be accepted as meeting the student
requirement to take the course. The university would provide the
students with pertinent information about the instructor and the
course, and pay the instructor on a per student basis.
This competition would raise the quality of the education and also
provide students with alternatives. For example a course on the
software lifecycle can be taught by different instructors in different
ways. One instructor could be more formal and mathematical than
another within the context of the same syllabus. This happens in
the
current paradigm. If the university is big enough and there are
sufficient students, the university may run two sections of a class
and the students choose if they want the version with or without
the
mathematics. In this paradigm, both versions would be available
to
students in smaller institutions.
For the smaller institutions, this scenario provides the same benefits
as teaming with larger institutions. It allows them to offer more
degrees than they could on their own. Since the syllabi will be
published there will be a convergence between the syllabi on specific
topics as taught by different instructors. The differences will
be in
the persona of the instructor. This might allow different instructors
to charge more or less for their courses depending on their workload,
their reputations or some other factor. Students may be prepared
to
pay slightly higher tuition rates for certain instructors, and
the
institution gets its percentage. The convergence of syllabi may
lead
to greater uniformity in what is actually taught in graduate degrees
in systems and software engineering.
Intellectual property issues
In this alternative paradigm, the instructors own the rights to
the
content of the course; the university owns the rights to the
information in the specific institutional format. This is similar
to
the way authors and publishers split the rights to the textbooks.
This is a simple division and totally bypasses problems in the
current
paradigm.
Here's an example of a problem that would be eliminated by this
paradigm. The GSMT at UMUC (http://www.umuc.edu)
offers a Master of
Software Engineering (MSWE) degree. Students may take classes in
the
classroom or via distance education. The curriculum contains one
of
the few graduate level classes on Software Maintenance (MSWE 648)
(Kasser and Kerby 1999), and one of the still fewer classes on
the
topic available in via distance education. The course content was
developed by the Program Director in 1998. He also taught the class
for three semesters. As creating the course and upgrading it each
time
he taught it was part of his duties, the program director created
a
"work for hire" and UMUC owns the course. The program director
has
since left UMUC but continues to teach the course as an adjunct
professor. The course is scheduled to run in two sections (classroom
and distance mode) in spring 2000 and needs upgrading. The module
on
Y2K needs a major upgrade and some of the other modules need minor
tweaks to stay current. The adjunct is going to make the upgrade.
Who owns the rights to the upgraded parts of the course? If the
course
remains at UMUC and is only taught in the classroom and via distance
education, the matter is not very serious since UMUC and its students
are the only beneficiaries of the changes. However, UMUC has begun
to
offer its courses to other institutions. Since MSWE 648 is one
of the
few graduate level classes on the subject of software maintenance,
it
should be a very marketable course. Thus the ownership of the
intellectual property has financial implications to the person
who
modified the course.
Conclusions
This article has covered some initial thoughts on an alternative
relationship between instructors and institutions and the implications
of the changes in the relationship. If the model is adopted, there
could be a fundamental change in the nature of the university in
the
area of software and systems engineering. The institution would
no
longer be a place where students come to learn from academic leaders,
it would however still be a place that provides the infrastructure
for
learning as well as continuing its role in providing graduate students
with research opportunities. What do you think?
What's in it for me.
I developed MSWE 648 when I was at UMUC (Kasser and Kerby 1999),
and
continue to teach it as an adjunct professor, so the intellectual
property issue is very relevant. I'm now at the Systems Engineering
and Evaluation Center at the University of South Australia (UniSA).
I'm in a research role without the requirement to teach. However,
since I like teaching, I'm developing two graduate level courses
in
systems and software engineering. Since I'm not required to teach
at
UniSA, the courses are mine, and will probably be delivered at
UniSA
under a separate contract. I'm also well versed in distance learning
techniques and could teach them via distance education using audio
enhanced lectures or via the short one-week intensive seminar model.
The courses are in:
* Requirements Engineering, and
* Software Engineering Project Management
Requirements Engineering
The aim of the course is to equip students with the appropriate
understanding of the difficulty of writing good requirements, the
use
of requirement management as an approach for controlling change
and
measuring the degree of completion of a project over the development,
build, test and deliver, portion of the system and software life
cycle. On completion of this subject students should be able to:
* Elicit requirements from customers;
* Write verifiable requirements;
* Critique and clarify poorly written requirements;
* Evaluate COTS products for degree of conformance to project
requirements;
* Use the Categorized Requirements in Process (CRIP) (Kasser 1999)
approach to measuring the degree of completion of a development
project.
Software Engineering Project Management
The aim of the course is to equip students with the appropriate
understanding of the reasons for the failures of software development
projects, the factors leading to cost and schedule overruns in
software development projects, the rational and application of
industry standards to the software environment, and alternative
architectures that minimize defects in developed software. On
completion of this subject students should be able to:
* Understand the defects in the current software project management
paradigm;
* Identify major causes of cost and schedule overruns;
* Shape software designs into a testable framework;
* Develop software build plans that allocate high priority
requirements to early builds;
* Apply Industrial Engineering principles to software project
management.
Anyone with an interest in trying out some of the ideas discussed
above using these courses as prototypes please E-mail to
joseph.kasser@unisa.edu.au.
References
Kasser, J.E., Kerby, S., Teaching Software Maintenance Online via
(Mostly) Asynchronous Distance Learning , Forum for Advancing
Software Engineering Education (FASE), Volume 9 Number 10,
October
15, 1999.
Kasser, J.E., Using Organizational Engineering to Build Defect
Free
Systems, On Schedule and Within Budget, Portland International
Conference on Management of Engineering and Technology (PICMET)
1999, Portland, OR, 1999.
######################################################################
Teaming for Teaching:
Producing Effective Systems and Software Engineers
for the 21st
Century
Dr. Joseph Kasser (joseph.kasser@unisa.edu.au)
University of South Australia
Abstract
As we enter the 21st century, the demands on our technological
personnel are greater than ever. Universities wishing to meet this
growing demand for education in systems and software engineering
are
facing a scarcity of qualified seasoned systems and software engineers
who can teach the topic. This gap between the need and the capability
to train personnel is not an easy one to fill. This paper applies
an
industrial solution to the problem faced by individual universities,
namely synergistic teaming to provide educational opportunities
greater than those can could be provided by the individual
institutions.
INTRODUCTION
As we enter the 21st century, the demands on our technological
personnel are greater than ever. For example:
* Major government funded systems development has traditionally
been
characterized by cost and schedule overruns and other (spectacular)
failures.
* Employers need effective systems and software engineers to meet
the
demands of producing modern complex systems within the constraints
of schedule and budget.
* Building modern complex systems with international subcontracts
and
partners requires that the builders have a global perspective.
This gap between the need and the capability of the personnel is
not
an easy one to fill. Universities wishing to meet this growing
demand
for education in systems and software engineering are facing a
scarcity of qualified seasoned systems and software engineers who
can
teach the topic. Consequently the instruction provided to students
may
not be at the level program directors and students desire.
This paper proposes applying an industrial solution to the problem
faced by individual universities, namely synergistic teaming to
provide educational opportunities greater than those can could
be
provided by the individual institutions. The traditional approach
of
teaching theory in academia does not work too well in systems and
software engineering because it is a field that is evolving rapidly.
By the time a methodology gets into a syllabus the state of the
art
has moved on. In addition, while there are few proven theoretical
methodologies in the field, any literature search of the field
will
show there are a lot of empirical approaches that have been published
as symposia papers. Luckily, the part-time or adjunct faculty teaching
systems and software engineering tend to be senior level people
who
are doing systems and software engineering as a full time job,
and
are teaching part time. These people, not only teach the theory
as
expressed in the text books, they are in an excellent position
to
comment on the theories and tell their students what works and
what
doesn't work. In effect they have returned to the tried and true
approach to teaching engineering skills, namely the master-apprentice
model. This is the teaching model adopted in the Graduate School
of
Management and Technology (GSMT) at University of Maryland University
College (UMUC) from teaching courses in the Master of Software
Engineering and Master of Science in Computer Systems Management
Degrees.
Even resorting to adjunct faculty does not provide enough qualified
instructor candidates. While there are many experienced practitioners
who could teach systems and software engineering in general they
tend not to have terminal degrees[1]. The accreditation criteria
for
universities which requires a specific minimum of instructors with
terminal degrees for teaching at the graduate level thus tends
to
prohibit the use of their otherwise qualified instructors and
significantly reduces that pool of available talent. Universities
which are able to find experienced qualified practitioners with
terminal degrees hire them to teach and then may find out that,
while
particular persons may have an excellent grasp of the subject,
they
cannot teach adult learners (mature students). And, as this situation
is only discovered in the classroom, it becomes a lose-lose situation.
The students suffer due to the lack of instruction, the instructor
goes through a bad experience, and the university loses a valuable
resource. Teaming has traditionally not been viewed as a solution
to
this problem because universities in a geographical area are
competing for students among the same population. However the advent
of the world wide web coupled with the growth of distance learning
technology have made teaming a viable solution to the problem in
certain situations. Consider the requirements for successful teaming
and the implications thereof.
CONCEPT OF OPERATIONS
As with any good engineering project, it begins with a vision,
commonly known as a concept of operations. A team of universities,
each well known in their area (geographical or expertise) offer
a
joint graduate degree in systems and software engineering or in
any or
both of the separate disciplines. As far as the team is concerned:
* One or more topics is/are taught only by the institution with
the
recognized expertise. The University of South Australia
(UniSA),
for example, would provide expertise in the systems engineering
topics by virtue of its association with the System Engineering
and
Evaluation Center (SEEC) in suburban Adelaide.
* Several topics are taught by two or more institutions
* The remainder of the topics is taught by all institutions in
the
team.
* The team is made up of institutions well separated by distance.
Each
is located in an area with potential students. For example
UniSA
could team with an institution in England, another in the
Washington
DC area of the United States of America (e.g., UMUC) and
one in
India[2].
The courses are offered in several formats to suit the lifestyle
of
the adult learner. These include:
* Traditional synchronous classroom sessions over the course of
a
semester.
* On-line sessions over the course of a semester via distance
education in synchronous or asynchronous formats.
* Short three or five day synchronous seminars[3].
* The executive format of consecutive synchronous weekend sessions
enhanced with web-assisted asynchronous extensions.
Students take courses from the institution of choice via their method
of choice. In the situation in which a course is offered by more
than
one institution, the students will soon learn which institution
and
which instructors are more suited to their needs and plan their
studies accordingly. This competition for students will tend to
increase the quality of the courses and ensure that they remain
reasonably current. For example, several students in the now
terminated joint Master of Software Engineering (MSWE) degree offered
by the University of Maryland at College Park (UMCP) and UMUC did
express preferences as to institutions and instructors in acquiring
knowledge of specific topics[4].
While each university locates instructors, the pressure on program
directors to find instructors for every course is lessened.
REQUIREMENTS FOR TEAMS
Theoretically forming teams should not be too difficult, in practice
it will be a major accomplishment. The requirements for successful
teams in academia are the same as those for successful teams in
industry, namely:
* Each member has something to contribute and lacks some capability
provided by other members of the team.
* The members have compatible cultures. In the United States there
tends to be two kinds of universities, the research university
and
the teaching university. As UMUC and UMCP found out, incompatible
cultures are a major impediment towards forming a successful
team.
* The institution understands the needs of, and cares for adult
learners.
* The institutions provide most if not all of the systems and
software engineering body of knowledge, or at least the
subjects
taught in current degrees in systems and software engineering.
* The full-time faculty at each institution have worked in the
field
successfully before entering into academia.
* Most of the classes are taught by adjunct faculty who are doing
what they are teaching. If they are not doing it while teaching,
then they should have done it within the last two years.
* One institution has to administer the program, the others provide
the quality control. This is the principle of checks and
balances.
* As important as the instruction is the access to current journals
and textbooks, and databases. The ability to provide these
capabilities are critical when the student body is at a
distance.
Providing on-line access to the data is a service provided
by more
and more institutions, however providing access to physical
books
and journals is more difficult. While UPS and Federal Express
can
provide this capability overnight in the continental United
States
at a reasonable cost, the cost of providing the service
internationally is still prohibitive. The international
members of
the team provide the physical materials in their geographical
areas.
In practice however, teaming will not be simple. However, it is
the
way of the future. Experience has already shown that it requires:
* major commitments by each institution and,
* personnel in each institution committed to the vision of the
team
and providing their students with the best educational opportunities
they can.
The challenge in forming a successful long-lived team is that it
will
be a true example of engineering a complex system and may even
end up
as a case study in one of its own classes. Teaming is starting
to
happen. For example:
* UMUC and UMCP had a joint graduate program in Software Engineering.
When the joint program terminated in May 1999, UMUC converted
the
degree to the on-line format while continuing the phase
out of the
joint students and as of September 1999 it was their fastest
growing program (Kasser, et al.,1999).
* UniSA is actively collaborating with University College, London
in
providing courses in systems engineering.
* Informal 'teaming' is also taking place wherein individual
instructors teach at more than one university. However at
this time,
this informal teaming does not seem to cover the situation
where the
same instructor teaches the same or similar classes at the
different
institutions.
OTHER BENEFITS OF TEAMING INTERNATIONALLY
Other benefits include:
* The institutions in the team are not competing for students who
wish
to study in the classroom.
* Students are exposed to other ways of doing things in other nations
and cultures. This exposure comes from both the instructors
and
their classmates.
* Students in the on-line classes work in teams on projects with
people. This constructivist approach to learning provides
both the
global perspective and the ability to interact with co-workers
in
distant time zones.
* Australian and British universities offer research degrees at
the
Masters and Doctoral levels which do not have residency
requirements. By teaming with a Stateside university,
the degrees
would be available to the professional in the USA who does
not have
the time to spend in a 'residency'. This opens a new market
to the
offshore universities. In addition, as well as raising the
effectiveness of systems and software engineering, making
this type
of degree available in the USA would, in the long term,
provide a
greater pool of subject matter experts with terminal degrees
for
teaching in the classroom.
CONCLUSIONS
Institutional teaming for teaching systems and software engineering
offers benefits to both institutions and students. As such it should
only be a matter of time before the first such team is formed and
offers world class graduate education in systems and software
engineering.
REFERENCE
Kasser, Joseph E., et al., "Bringing the Master of Software
Engineering Degree On-line at University of Maryland University
College", SETE-99, Adelaide, Australia, 1999.
FOOTNOTES
1 A terminal degree is generally one at the Doctorate level.
2 England provides entry in the European Union as well as the British
defense industry. Washington DC is the location of many
contractors
providing systems engineering services to the U.S. Government.
India is a growing area in the field of systems and software
engineering and students seem to be one of its major exports.
3 The short seminars allow for instructors to be flown to their
students, in the manner in which UniSA personnel offer courses
in
the United Kingdom and makes use of foreign talent in Australia.
4 It was not at all one-sided. Some students preferred UMCP, others
UMUC.
######################################################################
Kenneth L. Modesitt
Professor and Chair
and
Bruce R. Maxim
Associate Professor
Department of Computer and Information Science
University of Michigan-Dearborn
For those readers with enough gray hair (or none!), step back in
time with us to 30 years ago, say 1968-70. At that time,
Computer
Science (CS) programs were in their infancy. One of the authors
had
graduated with a B.S. in Mathematics from the University of Illinois
in 1963, having become enamored with the math and EE courses that
used the Illiac I (von Neumann Princeton-class 1000-word
Williams-tube computer). Then he took a M.S. in CS from Stanford
in
1965 (first in the nation), pursued a Ph.D. in CS from Carnegie
Tech
(one of the first in the nation) and took a position teaching CS
at
Colorado State University. There were no textbooks, let alone
very
few faculty with advanced degrees in CS. The (few) computers
in
1967 were mostly mainframe with punched card input, and all
assignments were distributed, courtesy of an over-worked ditto
machine.
Did CS survive this stage of infancy? You could say that!!
We
believe that Software Engineering will experience a similar
phenomenon. CS "started" over 50 years ago, and SE was not
"articulated" until 1968.
To be sure, there will be shortages of people with advanced degrees
in software engineering initially. However, the field will
continue
to grow as qualified people with degrees in CS, Computer
Engineering, IS, and others will spearhead the growth. In
fact, the
future is even brighter, we feel, as a substantial number of people
with excellent relevant experience are now in industry and the
government, including the military. These individuals are
a superb
source of faculty, both full-time and adjunct. They possess
the
"trial-by-fire" experiences, and the reflective nature to appreciate
the "lessons learned" from such experiences. Competition
has forced
them to maintain state-of-the-art competency. They perforce
have
had to teach others in their organizations the fundamentals of
software engineering theory and practice.
The only Ph.D. program for Software Engineering in the nation,
available from the Naval Postgraduate School in Monterey, CA
(http://www.cs.nps.navy.mil/)
has students who fit the profile
above. Naturally, they will be very valued additions to the
profession. We, along with a whole bunch of other universities,
would LOVE to hire some of them!
So, yes, there will be a shortage of faculty who have a Ph.D. in
Software Engineering, but that will be temporary and will not
severely hamper the growth of the discipline.
Kenneth L. Modesitt
Professor and Chair
Modesitt@umich.edu
(313) 436-9145
Department of Computer and Information Science
University of Michigan-Dearborn
4901 Evergreen Road
Dearborn, MI 48128-1491
And another viewpoint!
Based on what I have seen in our department, the SE faculty shortage
is far more severe than the CS faculty situation. In addition to
having very few SE Ph.D. programs, many institutions have very
few
graduate courses in the SE area of study. It is hard to find more
than six current textbooks in the areas of User Interface Design
or
Software Quality Assurance (though it is possible to find books
on
Software Reliability). The textbook selection for a first SE course
at the graduate or undergraduate levels is fairly rich (probably
20
or 30 current books) - finding good materials for an Advanced SE
course is tough.
I believe too that the extreme shortage of trained SE in the
industrial and commercial sectors (and the high salaries offered
relative to academia) makes it hard to convince students to finish
doctoral degrees. There is also still a bit of snobbery among
theoretical CS faculty in our department who regard SE as too
applied to be real research, consequently interested students may
not be doing thesis work on SE topics.
It will be hard to change this situation, until more SE degree
programs are up and running (BSSE, MSSE, Ph.D. or D.Eng or D.Sc).
The usual approaches in the past have been to try and attract
practitioners to come to academia on a part time basis and to look
to retraining programs for CS, EE, and Management faculty to broaden
their knowledge of SE. Summer institutes and short courses
are ways
of retraining. Encouraging collaborative research and publication
on SE topics is another way of doing this. Integrating SE topics
in
traditional CS courses is a much longer solution until the faculty
are in place to begin offering more separate SE courses at the
graduate level. I am afraid the situation can only change
slowly
through natural evolution - unless something drastic changes the
resources available to address the problem.
Bruce R. Maxim
Associate Professor
Bmaxim@umich.edu
(313) 436-9155
Department of Computer and Information Science
University of Michigan-Dearborn
4901 Evergreen Road
Dearborn, MI 48128-1491
######################################################################
Coping with the Faculty Shortage
Mark Sebern
Program Director, Software Engineering
EECS Department
Milwaukee School of Engineering
1025 N. Broadway
Milwaukee, WI 53202-3109
USA
414-277-7213
sebern@msoe.edu
http://www.msoe.edu/eecs/se/
http://www.msoe.edu/~sebern/
With a booming job market for computer-related skills, it is not
surprising that recruiting software engineering faculty can sometimes
be a daunting task. The specific challenges may vary, however,
depending on the characteristics of each educational institution.
The
Milwaukee School of Engineering is a university historically focused
on undergraduate engineering, though construction management,
business, nursing, and a number of masters programs are also offered.
Applied research and interaction with industrial partners is
encouraged. MSOE offers undergraduate engineering programs in
architectural, biomedical, computer, electrical, industrial,
mechanical, and software engineering, but not in computer science.
In faculty hiring, emphasis is placed on teaching ability and
experience in engineering practice.
The bad news is that this emphasis limits the field of prospective
faculty candidates and to some extent places us in direct
competition with industry. The good news is that, for candidates
seeking the type of environment we offer, we don't have a lot of
competition. In recent years, we have been able to attract a number
of excellent faculty. Of course, continuing enrollment growth in
computer and software engineering means that the job is never done.
So far, we have managed to keep up with demand (more or less well)
by:
1) attracting practitioners with both academic credentials and
significant industrial experience who have reached a point in their
careers where a teaching position (with opportunities for applied
research and consulting) is an attractive alternative,
2) selectively recruiting traditional faculty candidates (both recent
PhD's and experienced professors) who have practical experience
from
previous employment or as a component of their academic work, together
with a strong interest in teaching, and
3) providing professional development opportunities for current
faculty to upgrade their skills and knowledge so they can make
a
greater contribution in growth areas such as computer and software
engineering.
Still, the challenge remains. As more software engineering programs
develop, it seems likely that competition for faculty will increase.
In an environment where sophomore engineering students are offered
$US60K to drop out of school and do e-commerce development, academic
pay levels can sometimes be an obstacle for promising prospects.
On the other hand, these are exciting times for software engineering.
Software engineering educators have the opportunity to exert
significant influence on the development of the next generation
of
practitioners. I remain hopeful that we'll be able to communicate
the
benefits of being part of that enterprise so that we can attract
the
faculty needed to make it a success.
And yes, since you asked, we ARE always looking for a few good profs!
######################################################################
Coping with the Software Engineering Faculty Shortage
-
A Viewpoint
Rayford B. Vaughn, Jr.
Associate Professor of Computer Science
Mississippi State University
Mississippi State, MS 39759
vaughn@cs.msstate.edu
(662) 325-7450
This author was absolutely delighted when contacted by Don Bagert
and
asked to provide a viewpoint for FASE on whether or not we are
faced
with a shortage of software engineering faculty and how to cope
with
it. This is an important topic for all of us as software
engineering
degree programs become more ubiquitous and as the discipline itself
begins to take on more of its own identity.
It seems clear that there is a shortage of software engineering
faculty - not entirely inconsistent with the overall shortage of
computer science faculty today. One only has to have experienced
a
faculty search effort within the last several years to arrive at
this
conclusion. There appears to be both a quantity and quality
problem
to cope with. The IEEE Computer Society and ACM Software
Engineering
Coordinating Committee's Accreditation Criteria for Software
Engineering addresses importance of quality faculty. In fact,
the
criteria includes a statement that "Faculty members teaching core
software engineering courses should have substantial practical
software engineering experience". Herein lies a critical
component of
faculty requirements that will exacerbate the shortage already
being
experienced today. One generally obtains such experience
in an
industrial setting working commercially or for a government agency.
Those that perform in this capacity and hold a computer science
(or
related discipline) doctorate are also normally in positions of
significant responsibility, compensated with a salary higher than
that
found in academia, and not encouraged or motivated to develop a
significant record of publications, teaching, or sponsored research
(all academic indicators of success).
The ability to demonstrate "substantial" practical software
engineering experience can be defined in various ways, but one
could
propose that this suggests a minimum of five years experience as
a
software engineer. Another accreditation criteria faculty
requirement
is that "...faculty must be able to interact effectively with software
practitioners." This suggests not only experience as a software
engineer, but also project management, team leadership, customer
relationships, lifecycle management, etc. Again, these qualifications
at the doctorate level are rare in both the academic and commercial
communities. In other words, the talent pool is sparse and
the
competition is keen.
How does one cope with this shortage? The following tactics
are
presented as "thoughts" for consideration and to promote a bit
of
dialogue:
1. Proactively recruit from industry and government organizations.
There are individuals that are looking for a lifestyle change and
to
whom the academic environment is appealing. These same individuals
are not likely to see traditional recruitment ads (e.g., CACM or
The
Chronicle) and not likely to respond to such search efforts.
This
author has seen better results by "targeting" such individuals
and
working with them one on one to solicit an application.
2. Be flexible in reviewing resumes. Look for "potential"
to publish
and to establish software engineering research program based on
years
of experience and interaction in the software engineering community.
It is unlikely that many applicants will have lengthy publication
records accompanying years of industrial experience. This
is not to
say that "no" publications is acceptable either - some evidence
of
publishing ability and peer review needs to be established.
3. Build the software engineering faculty with a "cooperative" mix
of
practitioners coupled with pure researchers. This allows
those
without experience to leverage the contacts and experience of those
who have it and encourages the more practical minded to explore
new
and innovative theory. The "team" must be balanced.
4. The tenure process should recognize contractual relationships
between faculty and software engineering industry in the same vein
that it recognizes a more traditional (e.g., NSF) research proposal.
Indeed - such contracts are the research test bed for many software
engineers.
5. Encourage more early "sabbaticals" with industry for young
software engineering professors that are seeking experience.
Today's shortage of software engineering faculty will likely continue
into the foreseeable future. This is not comparable, however,
to the
shortage experience by Computer Science as it emerged as a discipline
in the early to mid 1960's. Early Computer Science faculty
were
obtained from a variety of disciplines that used computers as a
tool
(e.g., physics, mathematics, industrial engineering, etc.).
Software
Engineering faculty will need to apply computer science and computer
engineering to a customer environment and will therefore likely
need
to be largely produced by those disciplines (with some exceptions
of
course).
######################################################################
The SE Faculty Shortage: Deja Vu, or Something New?
Donald J. Bagert
Professor and Associate Chair
Department of Computer Science
Texas Tech University
There is no doubt concerning the fact that there is currently a
major
shortage of faculty for all computing disciplines. In the
case of
software engineering, the situation is compounded by the fact that
there are few doctoral programs (and apparently only one in North
America, at the Naval Postgraduate School) in the discipline.
At the
same time, events in the U.S. and Canada regarding accreditation
and licensing will likely spur the creation of new undergraduate
programs in software engineering. This is similar to the
situation
faced by computer science in the 1960's and 1970's. So, the
question
is, does the solution to the faculty shortage lie in that past
experience? The answer, in my opinion, is that there are
some
similarities, but also several differences. Among the similarities:
1. Adjunct faculty can be used in the short-term to fill some
of the
gap. However, adjuncts have no vested interest in the program
as
compared to full-time tenure-track faculty, so this was not a
long-term solution for CS thirty years ago, nor it is one for SE
today.
2. Software Engineering programs are growing primarily out
of two
different departments: electrical & computer engineering (ECE)
and
computer science. In the case of computer science, it was
Mathematics
and Electrical Engineering. As with Math and EE in the sixties
and
seventies, ECE and CS faculty can be retrained (or have their training
supplemented) in order to become productive software engineering
faculty.
3. At the same time, there are many in both engineering and
computer
science, even those teaching and doing research in software
engineering, that believe that SE is not a separate discipline,
which
mirrors the situation facing CS thirty years ago. (There
are some
amazing parallels: computer science is a science unlike any other,
since it grew out of an invention - the computer, while software
engineering is a unique new type of engineering, since it concerns
the engineering of a non-physical entity: software. In both
cases,
this has led to strong opposition to the respective disciplines.)
This situation can lead to less SE faculty being needed in the
short-term, because opposition to it as a separate academic discipline
slows the rate growth; at the same, it means that universities
may be
less cognizant of the eventual need for such faculty.
However, there are two major differences between the past situation
in computer science and the current dilemma faced in software
engineering regarding faculty, and it is in those differences that
universities should concentrate their search for solutions:
1. Educational delivery systems are much more sophisticated
than
thirty years ago. This makes the reuse of courseware in different
courses by different instructors (possibly even at different
universities) more feasible, as well as aiding long-distance
education. The question is: do such systems reduce the faculty
workload, or merely allow for a wider range of options for the
student? Formulating, implementing and evaluating potential
solutions
in this area have already begun, but much more work in this area
is
needed.
2. It will not be nearly as easy to create Ph.D. programs
in software
engineering as it was to create doctoral degrees in computer science,
due to the current climate in academia. The 60's and 70's
were times
of growth of new programs for colleges and universities in the
U.S.
Today, few new Ph.D. programs are created; often, creating a new
doctoral program means that another must be discontinued.
One
possible solution is joint Ph.D. programs across universities,
as
four universities are doing as the Master's level in the Oregon
Master of Software Engineering program <http://www.omse.org>.
Distance education could very possibly be used to help implement
such
programs.
In any case, the software engineering faculty shortage
is one that
needs to be addressed sooner rather than later. Hopefully
the
Computer Research Association (through its Taulbee Report on Ph.D.
in computer science and engineering) and the IEEE-CS/ACM Software
Engineering Coordinating Committee are the organizations that are
the best-positioned to do that, and hopefully, they will.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: Don Bagert (Academic/Misc Editor)
Last Month's Topic: Addendum
Last month, we discussed the top contributions of the century in
the area of software engineering education, training, and
professional (SEET&P) issues. A member of the panel,
Michael Ryan,
reminded me of an omission to the honorable mention list:
"I still have a soft spot for the results that emerged from the
IBM
Federal Systems Division activities in the 70s and early 80s.
I guess
it's because when I was trying to put together a course on S.E.
in the
early 80s and looking for quantitative data I found the analysis
they
provided really useful. Work such as Fagin's on inspection also
I
think helped identify the importance of process in developing software
- I remember at the time being surprised that a well organised
inspection process was so much better than test data in finding
errors."
Thanks, Michael. I also need to clarify your affiliations,
which were
stated as Dublin City University and Accelerated Encryption Processing
(AEP); Michael is a consultant to AEP, and not a member of the
their
staff. Sorry for the confusion.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Next Month's Topic: Top Ten Contributions - Don't
Forget to Vote!
Topic Editor: Don Bagert, Texas Tech University
Don.Bagert@ttu.edu
Last month, a panel of experts gave their opinions on what are
the top ten contributions of the century in the area of software
engineering education, training, and professional (SEET&P)
issues.
For the last month, we've been asking you, the reader, for your
opinions of the top ten contributions, and we've already gotten
many responses.
If you haven't voted already, go to
http://www.cs.ttu.edu/fase/topten.htm
Voting will end on Tuesday 8 February 2000, and the results will
be
reported in the February FASE.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
By: Don Bagert (Academic/Misc Editor)
Call for Guest Editors and Topic Suggestions
If you are interested in being a guest editor, or have any suggestions
for future topics, please contact me at Don.Bagert@ttu.edu.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
######################################################################
By: Don Bagert (Academic/Misc Editor)
IEEE Software Roundtable: Best Influences on SE
While the December 1999 FASE had a panel of seven experts
express
their opinions of the top ten contributions of the century in the
area of software engineering education, training, and professional
(SEET&P) issues, the January/February 2000 issue of IEEE Software
did
something similar for the entire SE field. Software Editor-In-Chief
Steve McConnell organized a roundtable of twelve members of the
publication's editorial and industrial advisory boards (including
FASE
top ten panelist Nancy Mead) to identify "The Best Influences on
Software Engineering" (the title of the article) over the last
fifty
years. Their list consisted of:
Reviews and Inspections
Information Hiding
Incremental Development
User Involvement
Automated Revision Control
Development Using the Internet
Programming Languages Hall of Fame:
Fortran, Cobol, Turbo Pascal, Visual
Basic
Capability Maturity Model for Software
Object-Oriented Programming
Component-Based Development
Metrics and Measurement
(R)Capability Maturity Model is registered in the U.S. Patent and
Trademark Office.
This excellent discussion can be found on pages 11-17 of the January/
February issue of Software.
######################################################################
By: Don Bagert (Academic/Misc Editor)
IEEE Software Letters to the Editor on Professional SE
The January/February issue of IEEE Software also contained
on pages
6-9 a number of letters to the editor concerning the previous issue
on Professional Software Engineering. Many of the letters
focused
on the licensing issue, with several of those writing expressing
their concerns about the licensing of software engineers.
One letter
contained a number of questions they felt were unanswered about
the
licensing issue, which was followed by a reply by Software Editor-In-
Chief Steve McConnell. The role of software design, software
engineering curricula, project management, and the SE body of
knowledge.
######################################################################
From: Peter B. Henderson <phenders@butler.edu>
Undergraduate
Software Engineering at Butler University
Peter B. Henderson
In 20 to 30 years from now, it will be interesting to look back
at
the predictions for the software and information technology fields
at
the turn of the century. Study of history often leads to
a better
understanding of the future. To capture practical applications
of the
sciences, engineering disciplines evolved. A typical undergraduate
computer science graduate is involved with practice rather than
pure
science. To make computer science a truly professional discipline,
it
will necessarily evolve toward engineering, specifically software
engineering. Similar arguments have been made in the past.
With the
move to license software engineers, the merging of the CSAB and
ABET
accreditation organizations and the potential for software litigation,
the time is ripe to develop undergraduate software engineering
programs emphasizing rigorous, disciplined approaches to software
design and development.
Our goal at Butler University is to evolve an undergraduate software
engineering program. The current computer science program
was
recently separated from the mathematics department; hence, the
beginning of one potential path of evolution:
CS -> CS & SE -> SE & CS -> SE
The primary foundations for a rigorous software engineering
curriculum should be mathematics and problem-solving; like the
other
traditional engineering disciplines. Accordingly mathematics,
math-thinking and problem-solving foundations must come early in
the
curriculum. Here discrete math will play a role similar to
continuous
math in traditional engineering. Students would take discrete
math
the freshman year, just as engineering majors are required to take
Calculus I and II the freshman year. Students would still
take some
continuous math to gain mathematical maturity, and have exposure
to
both modes of math thinking. Eventually I anticipate continuous
and
discrete math will evolve to be equals in our institutions of higher
learning, each complementing the other.
A prototype freshman discrete math course may be similar to the
foundations of computer science course I developed at SUNY Stony
Brook, and have taught there for the past 15 years. A description
of
this course follows with a recent survey by alumni found at
www.ic.sunysb.edu/cse113/survey/
"A rigorous introduction to the conceptual and mathematical
foundations of computer science. Problem-solving techniques
and
mathematical concepts that aid in the analysis and solution
of
algorithmic problems will be stressed. The course will
concentrate
on general problem solving principles, recursion and induction,
recursive problem solving, and discrete mathematics concepts
including: sets, logic, relations, graphs, functions, sequences,
induction, basic proof techniques. These concepts will
be motivated
within the context of computer science, and its applications.
Mathematical maturity at the level of pre-college calculus
is
expected."
Subsequent courses would build on these foundations by emphasizing
rigorous approaches to designing and developing software systems.
For
example, in CS-I (re-titled SE-I perhaps) students could apply
logic
to specify pre/post conditions and invariants, and to reason about
software systems.
Graduates of traditional engineering programs typically apprenticeship
with masters to learn their craft. Accordingly, the focus
of an
undergraduate software engineering program should be on concepts,
problem-solving, and building strong, rigorous foundations.
Practice
through software development projects is essential, but would not
be
the primary focus. Good instincts for software design/development
should be learned on the job.
A related key aspect of a successful software engineering program
should be some work experience, internships, summer jobs, coop
programs, etc. We plan to coordinate such experiences for
our
students with local industry in Indianapolis requiring students
to
have at least two work experiences.
What is the ideal curriculum for an undergraduate software
engineering program? No one knows, but we will strive to
evolve over
the next 7-10 years the best curriculum to meet the needs of our
students and industry.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Calls for Participation
######################################################################
From: Richard H. Thayer <thayer@csus.edu>
IEEE-CS State-of-the-Practice Survey
As you may already know, the IEEE Computer Society is launching
a new
initiative to create certificates in Software Engineering and Software
Engineering Project Management.
This initiative, entitled the "Competency Recognition Program,"
is
centered around the IEEE Software Engineering Standards. The Society
is in the process of establishing exams for both of these
certificates.
Part of the procedure for establishing a certificate exam is to
survey
qualified engineers and managers to determine the current
state-of-the-practice in software engineering and project management.
In an early running of the survey there were insufficient survey
participation to allow the Society to go ahead with the Software
Project Managers exam (the Software Engineering survey was completed
satisfactorily).
In this earlier version of the survey, answers were only accepted
from individuals who were currently working as project managers.
This
new version of the questionnaire will allow us to include people
who
have worked as project managers within the last ten years. This
would
also include individuals who while not practicing managers, are
through education, training, and knowledge, qualified to answer
questions about Software Project Management (check the 2-5 yrs
box or
the 6-10 yrs years box in Section 4.4 to indicate your level of
expertise). We need 200 more good answers. So please be one of
the
200. This is your chance to make a difference.
Please make sure that you check one of the answers under Software
Project Manager that is 10 years or less.
If you have completed the survey earlier, and indicated that you
were
a current project manager, please do not answer it again as this
will
double count you. If you completed the survey earlier and answered
that you were not a current project manager, please complete the
survey again. This time you will be counted.
The survey and is located at:
http://hopper.computer.org/jobanalysis.nsf.
Individuals that complete the survey can obtain a copy of the results
by sending me an email indicating that you have completed and have
sent in the survey.
Please forward this message to others who might be qualified to
take
the survey.
If you would prefer to complete a hard copy of the survey, please
email Ms. Stacy Saul at ssaul@computer.org
with your name, fax number
and/or mail address and indicate that you need the Software Project
Management version of the survey.
If you have any questions about the survey, you can email me at
thayer@csus.edu.
We hope to have this wrapped up by the first of the New Year. Please
submit you answers by 1 February 2000.
Richard (Dick) Thayer
Senior Member
IEEE Computer Society
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Conference Announcements
######################################################################
From: Susan A. Mengel <mengel@ttu.edu>
CSEE&T 2000 Final Program
Thirteenth Conference on Software Engineering Education and
Training
(CSEE&T 2000)
The Austin Renaissance Hotel
March 6-8, 2000
http://www.se.cs.ttu.edu/CSEET2000
Final Program
------------Monday, March 6
*Keynote Address
SE Coming of Age? Not Yet - James Bach, Consultant
*Panel Session
Software Engineering - Coming of Age or Reaching Too Far?....
D. Frailey (Chair), J. Bach, D. Dorchester, Bill Carroll, and
L. Tripp
*Paper Session: University/Industry
A Report on Industrial Transfer of Software Engineering to the
Classroom Environment
R. Vaughn, Jr.
Technology Transfer Issues for Formal Methods of Software
Specification
K. Abernethy, J. Kelly, A. Sobel, J. Kiper, and J. Powell
Achieving Organization Training Objectives with Short Course
Development
C. Smith
Lessons Learned from Teaching Software Engineering to Adult Students
J. Cusick
*Invited Workshop
Guide to the Software Engineering Body of Knowledge: Diffusion
and
Experimentation Strategy
R. Dupuis and P. Bourque
SWEBOK and Program Accreditation
G. Engel
SWEBOK and the Software Engineering Education Project
R. LeBlanc
Production of Software Curriculum Modules
G. Hislop and T. Hilburn
*Panel Session
Teaching Formal Methods Early in the Software Engineering Curriculum
A Sobel (Chair), H. Saiedian, A. Stavely, and P. Henderson
*Paper Session: Software Engineering Group Work
The Effects of "Pair-Pressure" and "Pair-Learning" on Software
Engineering Education
L. Williams and R. Kessler
A Survey on the Effectiveness of the Internet-Based Facilities in
Software Engineering Education
G. Succi and R. Spasojevic
Student Collaboration Across Universities: A Case Study in Software
Engineering
0. Brereton, S. Lees, R. Bedson, C. Boldyreff, S. Drummond,
P. Layzell, L. Macaulay, and R. Young
The Development and Trial of SEGWorld: A Virtual Environment for
Software Engineering Student Group Work
S. Drummond and C. Boldyreff
------------Tuesday, March 7
*Keynote Address
An Historian's View of Software Engineering - James E. Tomayko,
Software Engineering Institute
*Paper Session: Software Engineering Methods
Teaching Systems Analysis and Design Using Multimedia and Patterns
J. Cybulski and T. Linden
Student-Run Usability Testing
N. Wah
Experience Report: A Software Project Maintenance Course
J. Andrews and H. Lutfiyya
A Case Study Approach to Teaching Component Based Software Engineering
A Parrish, B. Dixon, D. Hale, and J. Hale
*Paper Session: Management Process
Teaching Software Project Management in Industry and Academic
Environments
J. McDonald
University/Industry Collaboration in Developing a Simulation Based
Software Project Management Training Course
J. Collofello
The Personal Software Process(SM) in the Classroom: Student Reactions:
An Experience Report
S. Lisack
(SM)Personal Software Process is a service mark of Carnegie Mellon
University
Mixing Software Project Management and Distance Education:
A Case
Study
D. Hanlon, M. Spence, and P. Pfeiffer
*Workshop
Developing Graduate and Postgraduate Software Engineering Courses
H. Edwards and J. Thompson
The University of Durham BSc in Software Engineering and Proposed
MEng
in Software Engineering: A Position Paper
C. Boldyreff
Issues Affecting Graduate and Postgraduate Software Engineering
Curricula
H. Ellis, H. Younessi, and J. McKim
A Model-Oriented Programming Support Environment for Software
Engineering Courses
C. Harrison and M. Naeem
Graduate Software Engineering in Practice: First Industrial
Contact
R. Manderson
Questions about Developing a Postgraduate Software Engineering Program
L. Thomas and G. Isaacs
A Graduate Course in Software Engineering
L. Werner
*Workshop
Real-Time Computing in Software Engineering Education
A. Kornecki
Teaching Scientific Method for Real-Time Software Engineering
D. Dampier and R. Wilson
Automatic Development Tools in Software Engineering Courses
J. Zalewski
*Posters
A Software Engineering Course that Integrates Education and Research
M. Blom, A. Brunstrom, and E. Nordby
Software Engineering Curriculum At The University Of Deusto
R. Cortazar, A. Barredo, J. Luis Del Val
The Maintainability Gap
A. Dingle and T. Hildebrandt
A Formation of the Career-Oriented Curriculum in the University
K. Huang
Domestic Control System STEM POS
M. Kamkar, C. Cederberg, and J. Edvardsson,
Interstel - A Seminar Model for Teaching Software Engineering
N. Kubilus
Software Engineering With Emphasis In Embedded System Design
H. Ma
Net-Centered Software Engineering Skills for the Next Millenium
A. Saad
The Implication of Different Thinking Styles on Software Engineering
Education
L. Thomas
SUPER: Towards a WWW-Enabled PBL Support Environment for Software
Engineering Education
K. Hou Vat
Change Management For Large Software Projects
P. Verma
Building a Next-Generation Infrastructure for the Software Education
Support
P. Yoon, Y. Chen, and S. Sambasivam
------------Wednesday, March 8
*Keynote Address
Beyond Software and Beyond Engineering - L. Belady, Executive
Director, Austin Software Council
*Paper Session: Curriculum
A New Software Engineering Programme --Structure and Initial
Experiences
P. Runeson
Standards-Based Software Engineering Student Textbook
E. Byrne
Did We Really Teach That?: A Glimpse of Things Students (Don't)
Learn
from Traditional CS1
R. Duley and P. Maj
A Proposed Curriculum for an Undergraduate Software Engineering
Degree
M. McCracken, L Hsi, H. Richter, R. Waters, and L. Burkhart
*Panel Session
Faculty Issues in Distance Education
G. Hislop (Chair), D. Bagert, W. Doube, J. Murtagh
*Paper Session: Computer Science/Software Engineering
A Perspective on Three Cooperating Courses
S. Mengel, L Carter, and J. Falkenberg
Formal Methods: Mathematics, Computer Science, or Software
Engineering?
G. Tremblay
A Framework Based Approach to Teaching OOT: Aims, Implementation,
and
Experience
B. Demuth, H. Hussmann, S. Zschaler, and L. Schmitz
Learning Real-Time Programming Concepts through VxWorks Lab
Experiments
A Kornecki, J. Zalewski, and D. Eyassu
*Workshop
Developing Undergraduate Software Engineering Programs
M. Sebern and M. Lutz
Initiating An Undergraduate Program In Software Engineering
B. Carter
Undergraduate Software Engineering Degrees in Australia
D. Grant
A Combined Curriculum Research and Curriculum Development (CRCD)
Approach to Software Engineering Education
B. Boehm, G. Kaiser, and D. Port
*Tutorial Session
Team Software Process
B. Cannon, T. Hilburn, and J. Diaz-Herrera
(SM)Team Software Process is a service mark of Carnegie Mellon
University
*Panel Session
Influence of JAVA on Software Engineering Education.
P. Knoke (Chair), W. Doube, J. Lewis, A. Ortiz, and A. Teruel
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Position Openings
######################################################################
From: Ted Baker <baker@dad.cs.fsu.edu>
Florida State University
TENURE AND NON-TENURE TRACK POSITIONS IN COMPUTER SCIENCE
Florida State University
Department of Computer Science
The Florida State University is in a period of significant growth
in Computer Science and allied areas. The department invites
applications for several tenure-track and non-tenure-track
positions at all ranks. Last year the Department of Computer
Science hired seven new faculty and the growth is continuing. New
faculty will have the opportunity to help shape the department's
future.
The department's primary focus for growth is Trusted Systems,
including computer and communications security, information
assurance, and software reliability. We are also looking
for
people in areas that support and can be related to this main
thrust, including system and network administration, performance
measurement, software engineering, and databases.
A second area of growth is Internet technology as applied to
education. The recent hiring Geoffrey Fox (previously of
Syracuse
University) has added to an already-active program in distance
learning.
In a third area, the department is working with the Computational
Science program to strengthen the faculty in scientific
visualization and databases.
For more information see http://www.cs.fsu.edu/positions/
--Ted Baker (FSU CS Dept Chair)
######################################################################
From: Byrav Ramamurthy <byrav@hamsa.unl.edu>
University of Nebraska, Lincoln
Computer Science and Engineering Department
The UNL CSE Department invites applications for several tenure-track
faculty appointments at Assistant, Associate, or Full Professor
rank
to begin August 2000. Applicants should have promise for
innovative
research and teaching in at least one of the following areas:
Database and information systems
Human-computer interaction
Physical design or high-level synthesis
Enterprise software engineering and electronic commerce
Geographic information systems
Distributed object technologies and middleware
Computer communications and network security
Theory and algorithms
and hold or be completing a Ph.D. in Computer Science, Computer
Engineering, or related field. Exceptional candidates in
other areas
will be considered.
The CSE Department offers both computer science and computer
engineering programs leading to BS, MS, and Ph.D. degrees and has
twenty tenured or tenure-track faculty, about 600 undergraduates
and
100 graduate students. UNL is Nebraska's comprehensive research
university with Carnegie I standing and membership in the American
Association of Universities. Last year, UNL received the
second
largest gift in its history to establish the JD Edwards Honors
Program
in Computer Science and Management. In conjunction with this
program,
the Department has several new named professorships.
Review of applications begins December 1, 1999, and will continue
until all positions are filled. A resume, statement of research
and
teaching interests, and three references letters should be sent
to:
Peter Revesz, CSE Search Committee Chair
Computer Science and Engineering Department
University of Nebraska, Lincoln
Lincoln, Nebraska 68588-0115
See www.cse.unl.edu; e-mail
search@cse.unl.edu; tel. 402-472-2401;
fax
402-472-7767. UNL is committed to a pluralistic campus community
through AA/EO, is responsive to dual career couples, and makes
reasonable ADA accommodations.
######################################################################
From: Byrav Ramamurthy <byrav@hamsa.unl.edu>
University of Nebraska-Lincoln
Department of Computer Science and Engineering
The Department of Computer Science and Engineering (CSE) at the
University of Nebraska-Lincoln (UNL) invites applications and
nominations for the position of Department Chair. CSE, with
nineteen
faculty, 594 undergraduates, and 105 graduate students, offers
degrees
in computer science and computer engineering, with programs leading
to
the BS, MS, and Ph.D. degrees. The Department is developing
internationally recognized research and academic programs in software
engineering, spatio-temporal information systems, distributed systems,
and communications and networking.
Qualifications: an earned doctorate in Computer Science, Computer
Engineering, or a closely related field, evidence of demonstrated
leadership and accomplishment in academic and research programs,
and
credentials appropriate for appointment as a tenured faculty member.
The candidate's academic credentials or background should permit
him/her to be a credible and effective advocate for CSE in both
the
College of Arts and Sciences and the College of Engineering and
Technology.
For a complete job announcement, details of the application process,
and additional information about CSE and UNL, please visit
http://www.cse.unl.edu/ or
contact Brian Wilcox at 402-472-3130 or
bwilcox1@unl.edu. Application
screening will begin December 1, 1999
and continue until the position is filled. Salary will be
competitive
and commensurate with qualifications. Women and minorities
are
particularly encouraged to apply.
The University of Nebraska-Lincoln is the state's land-grant
institution and premiere research campus. UNL has approximately
23,000 students. The University of Nebraska is committed
to a
pluralistic campus community through Affirmative Action and Equal
Opportunity and is responsive to the needs of dual career couples.
We assure reasonable accommodation under the Americans with
Disabilities Act; contact Ed Schmidt at 402-472-2891 for assistance.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Contact and General Information about FASE
The Forum for Advancing Software engineering Education (FASE) is
published on the 15th of each month by the FASE editorial board.
Send newsletter articles to one of the editors, preferably by
category: Articles pertinent to corporate and government training
to
Kathy Beckman <kbeckman1@erols.com>;
Academic education, and all
other categories to Don Bagert <Don.Bagert@ttu.edu>.
If the article
for a FASE topic where there is a guest editor, the submission
should
instead be to that person. Items must be submitted by the
8th of the
month in order to be considered for inclusion in that month's issue.
Also, please see the submission guidelines immediately below.
FASE submission format guidelines: All submissions must be
in ASCII
format, and contain no more than 70 characters per line (71 including
the new line character). This 70-character/line format must
be
viewable in a text editor such as Microsoft Notepad WITHOUT using
a
"word wrap" facility. All characters (outside of the newline)
should
in the ASCII code range from 32 to 126 (i.e. "printable" in DOS
text
mode).
[NEW SUBSCRIBE/UNSCRIBE INFORMATION - September 15, 1998]
Everyone that is receiving this is on the FASE mailing list.
If you
wish to leave this list, write to
and, in the text of your message (not the subject line), write:
unsubscribe fase
To rejoin (or have someone else join) the FASE mailing list, write to
subscribe fase <Your Name>
For instance, if your name is Jane Smith, write:
subscribe fase Jane Smith
But what if you have something that you want to share with everyone
else, before the next issue? For more real-time discussion,
there is the FASE-TALK discussion list. It is our hope that
it
will be to FASE readers what the SIGCSE.members listserv is to
that group. (For those of you that don't know, SIGCSE is
the
ACM Special Interest Group on Computer Science Education.)
To subscribe to the FASE-TALK list, write to
and, in the text of your message (not the subject line), write:
subscribe fase-talk <Your Name>
For instance, if your name is Jane Smith, write:
subscribe fase-talk Jane Smith
Please try to limit FASE-TALK to discussion items related to software
engineering education and training; CFPs and other such items can
still be submitted to the editor for inclusion into FASE.
Anyone that
belongs to the FASE-TALK mailing list can post to it.
FASE-TALK is also used by the editors for "breaking stories" i.e.
news
that we feel that you would want to hear about before the next
issue
of FASE comes out. (We do this sparingly, though.)
As always, there is no cost for subscribing to either FASE or
FASE-TALK!
Back issues (dating from the very first issue) can be found on the
web (with each Table of Contents) at
<http://www.cs.ttu.edu/fase/archive.htm>
in chronological order,
<http://www.cs.ttu.edu/fase/reverse.htm>
in reverse order, or
through ftp at
<ftp://www.cs.ttu.edu/fase/archive>.
The FASE Staff:
Don Bagert, P.E. -- Academic/Misc Editor, ListMaster, and Archivist
Dept. of Computer Science
8th and Boston
Texas Tech University
Lubbock TX 79409-3104 USA
Phone: 806-742-1189
Fax: 806-742-3519
Email: Don.Bagert@ttu.edu
URL: http://www.cs.ttu.edu/faculty/bagert.html
Kathy Beckman -- Corporate/Government Editor
Computer Data Systems
One Curie Ct.
Rockville MD 20850 USA
Phone: 301-921-7027
Fax: 301-921-1004
Email: kbeckman1@erols.com
Laurie Werth -- Advisory Committee
Taylor Hall 2.124
University of Texas at Austin
Austin TX 78712 USA
Phone: 512-471-9535
Fax: 512-471-8885
Email: lwerth@cs.utexas.edu
Nancy Mead -- Advisory Committee
Software Engineering Institute
5000 Forbes Ave.
Pittsburgh, PA 15213 USA
Phone: 412-268-5756
Fax: 412-268-5758
Email: nrm@sei.cmu.edu