The Problem
The process of adding and deleting DCS undergraduate courses,
changing pre- and co-requisites, and changing calendar descriptions
is currently well-defined.
There is an undergraduate committee that accepts such proposals
and decides upon them.
The process for making more fine-grained changes to course content
is not well-defined.
For example, it is not clear how to get a course to de-emphasize
one topic and emphasize another
For instance, suppose we need csc340h to teach certain aspects of UML so
that csc407h can depend upon the students having this knowledge.
Currently the "primary" instructors of both courses
(an ill-defined concept)
will get together and arrive at an agreement.
However, if those instructors change,
that way forward is unclear.
What if, for example,
a sessional instructor of csc340 decides
that they do not want to put the same emphasis on UML?
To date, it has been considered sufficient that the current
instructor(s) for the course in question can dynamically change
medium-grained aspects of the course they are teaching,
subject to the overall guidelines imposed by the calendar description.
These calendar descriptions, however, are often deliberately vague.
Lacking finer-grained control of course content,
efforts at curriculum renewal are frustrated.
Inevitably there arise overlaps and gaps in the curriculum,
which are pedagogically harmful.
If an instructor puts effort into developing a course
and meshing it with the current curriculum,
that effort may be wasted if a different instructor;
less experienced, less skilled, or less knowledgeable;
makes their own changes to the course.
For example, for a course I recently proposed,
csc309h (Programming in the Web),
I feel a responsibility in ensuring the course has
appropriate intellectual content and covers the right set of
topics.
Moreover, in various negotiations I have agreed with other faculty
over course content.
For example, I have agreed with monica schraefel
to include 4 lecture-hours on Hypermedia,
and I have committed to the undergraduate committee to include
only certain types of guest lectures.
However, even initially there will be three distinct instructors
across the three campuses.
There will also be many more sections of this course in the future,
taught by various and sundry.
How can I exercise due diligence,
and how can DCS via the undergraduate committee,
exercise due diligence regarding the future course content?
If a future instructor legitimately wishes to change the course
for the better, how do they go about doing that?
How is the change vetted?
Must I as the "course owner" be involved?
It is frustratingly undefined.
There is no process whereby positive changes are accepted,
and those changes perceived as detrimental are blocked
or modified into something positive.
Any attempt at meshing related courses in a fine grained fashion
are transient at best.
The effect of this lack of clarity is that we cannot
effectively engage in curriculum renewal.
Certainly, point efforts are made and improvement does happen
over the longer-term.
However, these changes do not happen fast enough
and are not sufficiently integrated with one another,
leading to outdated topics,
less-important topics being emphasized over more important ones,
gaps, overlaps,
and a curriculum that does not reflect departmental best-thinking.
Standardized Course Descriptions
I believe that at the heart of this set of problems is a lack of effective
control over medium-grained aspects of the curriculum.
This lack of control arises due to a lack of documentation.
The first step in regaining control is thus to
establish standardized course descriptions (SCDs) around which a
lightweight, fast-moving change control process can be built.
Without such course descriptions, faculty have no way of
determining what topics a course currently covers.
Indeed, this may be an ill-defined question, as the topics
covered will vary from lecturer to lecturer and from
year to year.
As well, if a desirable change is identified, DCS has no
standard way of specifying what the change should be,
and no way therefore of communicating the change to
future instructors of the course.
The SCDs do not have to be entirely prescriptive.
If there is latitude for instructors to choose topics
within a more general area, this can be described
as part of the SCDs.
Indeed, maximum flexibility in SCD content,
tempered by adherence to a particular format
and to minimum base standards,
is critical for general acceptance.
With a written artifact for describing course content
at a detailed level,
it becomes possible to specify a process for controlling
change to these documents.
The SCDs can be maintained in a form whereby tools can be
built to support this change control processes.
Once we then establish policies that will result in the courses
being taught according to the SCDs
(see Linkage section below),
we will have thereby gained change control over the curriculum.
Having effective change control over the curriculum
is a pre-requisite for larger-scoped, well-meshed curriculum changes.
Previous Comparable Efforts
In 1996, there was an initiative to collect course syllabuses.
The results are stored in ~clarke/pub/syllabuses.
As Jim Clarke writes,
"there were just a few syllabuses
provided, and essentially all of them came from well-run courses with
clearly identified owners. (We called them "fathers" then, or "parents"
if we were being more up-to-date.) Those particular courses already
had a good hand-holding arrangement in place; it was the *other* courses
that needed the collection of syllabuses."
Jim concludes, regarding the identification of course owners:
"There's the problem. If it could be done, it would be a very good thing,
I think, but we put considerable effort into pushing people in 1996, and
it just wasn't enough."
As we can see from Jim's comments, in 1996 there were two major issues.
- Identifying course owners for hard-to-place courses.
- Getting course owners to submit and maintain SCDs.
In the proposal that follows, I pay special attention to these
two issues, presenting motivators, policies, and procedures
to help address them.
Moving Forward
As an proof-of-concept,
I have defined a sample SCD format using XML,
and have implemented an XSL style-sheet to display
it as HTML in a Web browser.
Links embedded in the HTML allow one to perform actions
such as make a change request, object to a change request,
and subscribe to notifications for a given course.
The proof-of-concept uses one of my courses, csc407h as an example.
The final, browser-viewable HTML result is in the file
csc407.html.
The XML that was processed to produce the viewable result
is in the file csc407.xml.
All designated course owners would complete one of these XML files
for their course.
Defining the markup tags and providing a grammar for them
defines the format for SCDs.
These XML course descriptions are processed by an XSL stylesheet
to come up with the HTML page
(in case you're interested, the xsl transformation program is in course.xsl).
In production,
all such pages will be kept accessible to faculty
from a common index location.
Access rights for viewing, subscribing, proposing changes,
and actually making changes will be enforced by the system.
All changes will be kept under source control,
with the ability for users with appropriate rights to see
previous versions and the text of proposed changes.
What I developed is only a proof-of-concept,
and is by no means a completed effort.
Moving this proposal forward beyond this
demonstrative proof-of-concept requires the following steps.
- Define a format for standardized course descriptions (SCDs).
- Define surrounding processes and administrative procedures in detail.
- Implement technology for
- storing, viewing, archiving, modifying SCDs.
- requesting and objecting to changes to SCDs;
- subscribing to notifications of proposed changes;
- notifying subscribers of change requests,
objections to change requests, and changes.
- Provide on-line reference documentation for all of the above
- Provide sample, completed SCDs.
- Identify course owners, inform them of their assignments, post the assignments generally.
- Conduct a faculty training seminar regarding filling out an SCD, explaining the change policies,
and demonstrating/instructing on the use of tools.
- Collect and review initial SCDs.
- Manage change on an ongoing basis
Initial Creation Process
I propose that the Undergraduate Committee (UC) be responsible
for associating each course with a course owner.
As there are approximately 50 undergraduate CSC courses
and 50 active CSC faculty, this would result in each
faculty member taking charge of one course.
If a faculty member wishes to own more than one course,
that is permissible, and means that certain faculty members
may be let off the hook.
Initially, the faculty would be asked to voluntarily associate themselves
with one or more courses.
The UC will then meet, match the available
courses to the desired courses, and assign orphan courses appropriately.
Faculty are then informed of the courses for which they have
been assigned primary ownership, and the UC will hear appeals.
After the initial course owners have been assigned,
the UC must ratify any future change in owner.
The course owners must then fill-in their SCDs.
On-line documentation, samples, and training seminars should be offered
to faculty to assist them in filling out their SCDs.
Faculty will submit their SCDs via a Web-based automated system,
that would also check their SCDs for conformance to the
XML syntax and XML schema for SCDs.
Completed SCDs would be vetted by the UC for appropriate format, detail,
and general adherence to the calendar description.
The UC should not, at this stage,
concern themselves overly with the course topics listed.
Because all course owners
- will have been briefed on the purpose of the initiative;
- will have seen the extent of departmental support (Eugene should address its importance);
- will see its value;
- will see the investment made in detailing and documenting formats and processes,
and implementing tools in support of them;
- will have support in filling out SCDs;
as a result they will understand that their work will not go to waste.
I believe that this provides a firm foundation for helping to ensure that
the SCDs are appropriately filled in.
As well, designated course owners will have ownership
of their SCDs, and the process of enabling them to make
changes in their own SCDs will be very lightweight indeed
(see Change Control Process below).
By completing an initial SCD and
maintaining the SCDs as closely as possible to the way they actually
teach the course,
primary course owners can assure themselves that secondary instructors
will follow their guidelines.
These steps go beyond those taken in 1996,
where I speculate that one of the causes
for lack of enthousiasm was an expectation that the requested syllabuses would
ultimately go unused (as indeed, has proved to be the case)
This is a common cause of failed software development process initiatives:
the belief that effort spent on a process will go to waste,
which becomes a self-fulfilling prophecy.
Combating it requires consistent management commitment to the process,
and putting the processes into effect despite a potential lack
of enthousiasm and the presence of obstacles.
Once faculty see the system being used to make decisions,
and see how they are cut out of this decision-making process if
they do not partake,
they will accept the necessary overhead (small as it is).
More concretely, after course owners have been assigned and
a deadline put on for completion of SCDs, the following steps
should be taken to ensure conformance.
- reminders sent out 1 week before the deadline;
- 1 week after the deadline passes, a general e-mail to
all delinquent course owners from the UC;
- 3 week after the deadline passes, a general e-mail to
all delinquent course owners from the Chairman;
- 6 weeks after the deadline passes, a written letter
from the Chairman explaining that filling in SCDs adequately
is considered an expected part of the job for all faculty,
and requesting that they complete their SCDs within one week.
- 8 weeks after the deadline passes, re-assign course ownership
(this will mean lack of future control over the course,
and being ineligible to teach this course going forward).
Change Control Process
Once the initial SCDs are established,
faculty can then begin making controlled changes to them.
In order to encourage a sense of ownership and
not drown initiative in over-much red-tape,
I propose a negative process for owner-change control.
That is to say, an owner may propose changes to any part of
the SCD.
Unless anybody objects, the change will automatically
be ratified (by the system) two weeks later.
Owner-initiated changes are made by pulling the current
SCD out of source control (via a Web-based form),
making changes, and then checking it back in along with
a description of the proposed change.
Associated with an SCD will be a list of "subscribers".
Subscribers are notified by e-mail of any proposed changes.
Subscribers will automatically include the UC (or a designated
representative of it) for all courses.
Once a change is proposed and the subscribers have been notified,
they may go to the SCDs web page and look at the description
of the proposed change, and compare the old SCD
(which at this point is still in effect) against the
newly proposed SCD.
On the SCD web page will be a form that allows them to
make queries, make suggestions, and, ultimately,
officially object to a proposed change.
In essence, a threaded discussion takes place regarding the change.
If an owner-proposed change has no objections,
it automatically passes in two weeks, at which time the system
replaces the old SCD by the new, the change discussion thread
is archived, and subscribers are notified.
If the change is to calendar description or pre or co-requisites,
a special notification is made to the appropriate person
for passing on the change to the Arts and Sciences calendar
at the appropriate time.
If there is an objection, the issue is scheduled for discussion
in the next UC meeting
(which will take place monthly throughout the year),
and the UC committee will decide the issue.
Non-owners may propose changes as well.
In this case, the process is a positive one.
that is, the designated course owner must explicitly
approve the change within two weeks,
at which point it transitions into an owner-initiated change.
If the owner does not approve the change, the issue is scheduled
for discussion at the next UC meeting,
and they will decide the issue.
Processes for requesting additions and deletions of courses
will be integrated into the system as well.
Proposals for new courses will require a proposed SCD to be completed.
Thus all new courses will start life with a well worked-out and well-discussed
SCD.
The UC will make these decisions.
Linkage
One of the keys in the success of the venture
is establishing a linkage between SCDs and what
is actually taught in the course.
Jim Clarke does not believe this has historically been
much of a problem,
however he admits that it sometimes does happen.
One possible way to maintain this linkage is to
make the SCDs available to students, and have a question on the
DCS course evaluations asking students how closely the material
presented adhered to the SCD.
It could be a policy that instructors with consistently bad marks
on this question be officially encouraged to do better in the future.
As well,
by maintaining a linkage between what they teach and the SCDs,
primary course owners can assure themselves that secondary instructors
will follow their guidelines.
Sessional instructors should have the SCD stapled to their contracts,
and should agree to teach the curriculum as described.
Technology
XML technology for SCDs provides an excellent base for implementing the
necessary systems.
As the format of SCDs is XML text, it is accessible to all faculty.
All faculty are familiar with the use of text editing tools.
CSC Faculty and will have no difficulty understanding XML
grammar.
The XML files, being text-based,
can be kept on the departmental UNIX servers
under rcs source control.
PERL scripts fired via Web-CGI can verify security,
and perform all necessary check-in and check-out activities.
The PERL scripts can access and modify the contents
of the XML files using freely-available libraries
(to, for example, add a change proposal into an XML file).
A Web front-end using HTML forms backed onto the PERL CGI
programs will the be fairly straightforward to produce.
In all, I would estimate the technical effort to be approximately
3 person-months for a knowledgeable developer.
This can be accomplished as a summer project for a keen undergraduate,
or as part of a 4th year design project.
My colleagues in requirements analysis could use this
as a case study.
Conclusion
I believe that this SCD initiative, or something like it,
is a pre-requisite to implement effective
curriculum renewal of any scope at all.
If properly resourced and managed,
there is every reason to believe that it will be a successful
initiative that will be of great benefit to the training
of computer scientists at DCS.
Most importantly, implementing such an initiative
would remove frustrations from existing and new faculty
who try valiantly to improve the curriculum.
Such an initiative, successfully executed,
would be a model for other academic departments
throughout this University and others,
and help us to maintain a competitive edge
in attracting students and faculty.