Forum for Advancing Software engineering Education (FASE)

Volume 11 Number 06 (137th Issue) - June 15, 2001

 

Note: If you have problems with the format of this document, try

<http://www.cs.ttu.edu/fase/v11n06.txt>

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Table of Contents

 

This Issue's Topic: Teaching Software Project Courses

Introduction

by Stan Jarzabek, Guest Editor

Necessary Support for Students Who Take a "Project Course"

by Y. Akiyama and Y. Matsumoto

A Work Product Based Software Engineering Project Course

by Jurgen Borstler

Innovative Software Engineering Education

by Larry Bernstein and David Klappholtz

Software Engineering Project Course at University of Hawaii

at Hilo

by John Gersting

An Undergraduate Software Engineering Project Course at UCSC

by Donna Stidolph and Linda Werner

A Software Project Course at Norwegian University of Science

and Technology

by Letizia Jaccheri

A Software Engineering Project Course at the University of

Texas at Austin

by Vicki L. Almstrum

Real Software Engineering Projects at the University of

Sheffield

by Mike Holcombe

Software Engineering Project Course at Gannon University

by Steve Frezza

Software Engineering Project Course at California State

University, Sacramento

by Richard H. Thayer

Using Critical Essays in a Project Course

by Sally Jo Cunningham

Projects in Real-Time Software Engineering Courses

by Janusz Zalewski

Software Engineering Project Course at National University

of Singapore

by Stan Jarzabek

Upcoming Topics

Software Engineering as a Profession in the United Kingdom

Articles

Ideas and Issues in Software Engineering Education

by Tom Hilburn

Book Reviews

"Software Fundamentals: Collected Papers by David L. Parnas"

reviewed by Don Bagert

News Items

ICSE Holds Panels on Software Engineering Education, SWEBOK

New SE Professional Society Holds Workshop

CCPE and Microsoft Agree on Use of "Engineer" Title

UT-Dallas to Launch Software Engineering Degree Program

Parnas Writes Pro-Licensing Article for Canadian Magazine

Calls for Participation

TOOLS USA 2001

Position Openings

Illinois Wesleyan University

Contact and General Information about FASE

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

From: Stan Jarzabek <jarzabek@cas.mcmaster.ca>

 

This Issue's Topic: Teaching Software Project Courses

 

Guest Editor:

 

Dr. Stan Jarzabek

Department of Computer Science, School of Computing

National University of Singapore

 

Introduction:

 

The below papers and reports describe academic project courses taught

at thirteen universities. Not surprisingly, we find a wide range of

approaches. Most of the courses emphasize the importance of exposing

students to "real world" industrial experiences. Students have

to clarify requirements with customers, while they

work on the design and implementation. Some other courses emphasize

application of "best practices" (such as architectural design

and design for change) in a systematic way.

Different types of project courses tend to focus

on training different software development skills. Knowing how

to communicate with customers concerned with business issues

and how to deal with fuzzy and unstable requirements is as

important as the ability to communicate with other members

of the development team, apply architectural design, define

component interfaces, design for change or plan incremental

development. Students learn about these things in earlier courses,

but only in a large-scale, team-based project students can

really appreciate the practical value of what they have learned.

In the April 2001 issue of FASE, Tom Hilburn calls for balanced

software engineering curricula that would give equal attention

to both "real world" experiences and applying software engineering

principles. In the first paper below, Yoshiro Akiyama gives us

an industrial perspective on academic project courses

in which he further enforces Tom's views. Trying to address all the

educational objectives within a single project course may be

difficult, if not impossible. Perhaps, we should design a series of

project courses that will let students gradually master different

types of development skills, so that, at the end, our graduates know

how to cope with challenges of real world projects in a systematic

(i.e., based on principles and "best practices") rather than

a chaotic way.

 

We believe readers will find the perspectives on teaching project

courses presented in papers below interesting and inspiring in

refining their software engineering curricula. We also hope that

papers will stimulate further discussion and exchange of opinions

on this topic.

 

######################################################################

 

Title: Necessary Support for Students Who Take a "Project Course"

 

Authors:

Y. Akiyama, e-mail:akiyama@ieee.org

IBM Global Services, IBM Japan Ltd.

Y. Matsumoto, e-mail:yhm@sft.cs.musashi-tech.ac.jp

Musashi Institute of Technology

 

 

Abstract:

 

This paper addresses key concerns on how to introduce software

process and engineering disciplines into academic undergraduate

level education in such a way that there is an understanding of the

total picture of a software product development project as team

effort. In industry, improving process and disciplines has been

expected for realizing better quality and productivity in problem

solving or competitive software systems product development. Such

team (project) effort can be managed through software process for

success.

 

Detailed Description:

 

Hilburn [1] brought up an interesting discussion, "... to what degree

should a project course incorporate real world experiences?" where

"Real World" addresses software projects in industry. In this short

note, a few suggestions for designing the academic project course

program are mentioned after discussing the characteristics of

software projects in industry.

 

One critical issue that we learn from an industrial project is how

to deal with the complexity of projects. The complexity range may

be measured by the attributes such as the size of product or

deliverable, skill, process, stake holder's role, time duration,

budget, contract, and the relations among them. It is noted that a

staff member cannot execute a project alone, but it must executed

by a group of staff members who have skills that effectively

supplement each other.

 

To cover the entire complexity range, multiple project (educational)

courses are designed and provided in industry to help employees to

develop skills and capabilities as a long-term education program

with or without OJT (on the job training.) The scope of each course

is defined according to the required technical matters (a project

type), software process, and job roles, in addition to the

importance of customer satisfaction and quality needed for the

project's success, no matter how those items are theoretically

related and integrated.

 

Two ideas to improve the quality of the education program are

introduced as follows. The prerequisite for a project course is

specified to make sure that the students know the terminology,

concepts, engineering disciplines, basic skills, and workable or

best practices that are assumed. "Realistic training" is included

so that the experience will help the attendees to understand what

they would do for the goals of a similar project.

 

After completing such a series of project courses, however,

"trouble" may be found in the form of a project delay, skilled

resource shortage, frequently changing requirements, or a lower

quality of deliverables, just before the closeout phase. This may

occur, although the project progress has been tracked, reported,

reviewed, and agreed upon by the other stakeholders.

 

Engineering on what and how staff members work together may be

developed as the combination of engineering on a software system

and engineering on a software process that is defined by the

collection of activities, including technical decisions and workload

estimations. Let us call the engineering on a software process as

the software process engineering and the combination of the two

engineering areas as the project engineering to distinguish them

from one another. Industry practices and lessons learned should be

understood based on project engineering view point, as long as they

are technical.

 

The initial components of project engineering may be software

engineering components, TSP(SM), PSP(SM), and some basic quantitative

practices for decision making and estimation. Interestingly, TSP(SM)

and PSP(SM) provide practices to estimate (technically) the workload

that comes from non-technical human error.

 

Concerning project engineering, let us consider Hilburn's

question. It is preferable for a student to develop skills and

knowledge totally balanced from the project engineering viewpoint.

In this sense, the industry's project practices and experiences may

be introduced into the academic education but require very careful

considerations.

 

Undergraduate students learn the concepts and technologies included

in the software engineering education course one by one at the

beginning. For example, the object-oriented course may give lectures

on such topics as object-type, inheritance and overloading one by

one, and an exercise for each of the subjects.

 

Let us consider what happens then if an exercise, "design a library

system", is given in the last part of the software engineering

course. This exercise includes many technical problems and problems

related to the software process especially related to team working.

It is noted that the students are really interested in how to apply

The software engineering disciplines, just learned, to the given

Problem and not in software process that is unknown to them. As

easily expected, they may need to spend more time to define their

software process in some way. Since this may appear meaningless to

students, an appropriate software process must be given to the

students in advance so that they apply the software engineering

disciplines properly along with the software process and understand

how it helps the application of the software engineering disciplines

to produce the ultimate output.

 

Similarly, the description of the software engineering disciplines

needs to be given to students who have learned only the engineering

of a software process. Thereby, solving the problem should be easily

accomplished. It is interesting to note that students learn the

TSP(SM) process by the textbook that describes the concept and the

TSP(SM) process.

 

Students are assumed to always know how to formulate problems at the

application function level. Most likely a student who works well

on this problem formulation, will communicate with others well in a

different phase.

 

The totality (integration) of engineering a software (system) and a

software process should be designed in a project course so that

students will be able to learn the importance of team working

and how a realistic project is defined, executed, and controlled

for maximizing the team's performance.

 

References:

T. Hilburn, "So Let's Make that Software Project Course

'Real-World'?", FASE, Volume 11, Number 4, April 2001.

B. Cannon, T. Hilburn, and J.Diaz-Herrera, "Tutorial: Introduction

to the Team Software Process(SM)", CSEE&T2000, Austin TX, March 2000.

W.S. Humphrey, "A Discipline for Software Engineering", Addison

Wesley Longman, Inc. 1995.

 

(SM)PSP, TSP and Team Software Process are service marks of Carnegie

Mellon University

 

######################################################################

 

Title: A Work Product Based Software Engineering Project Course

 

Author: Jurgen Borstler (jubo@cs.umu.se)

Institution: Dept of Computing Science, Umea University, SWEDEN

 

Summary Page:

 

The type of your project course:

 

1. Industry involvement: see below

2. Projects proposed and supervised by faculty members in areas of

their expertise.

3. Project(s) formulated and conducted by a small number of faculty

members specializing in Software Engineering, with faculty members

and teaching assistants supervising student teams.

4. Other: please describe

 

==> 1 and 4: We accept project proposals from faculty members,

external organizations, and industry (usually about half the

projects have industry involvement); supervision by faculty

members only.

 

The project course is taught at:

1. undergraduate level

2. graduate level

==> Both: 3rd (75%) and 4th year students.

 

The objectives of the project course:

 

1. degree accreditation concerns

2. professional licensing concerns

3. better prepare students for industrial projects,

4. develop ability to work in a team,

5. enhance communication skills and writing skills,

6. enhance project planning skills,

7. other objectives - please describe.

 

==> 3-6, 7: Teach some advanced OO concept; follow defined processes.

 

Your project course is offered in the:

1. general Computer Science degree

2. Software Engineering degree

3. other - please indicate.

 

==> 1

 

Project workload:

1. project is a part of a general Software Engineering course

2. full-fledged project course with workload equivalent to:

for example, a typical 1 term course (13 weeks, 3 lectures per

week)

 

==> 2: 10 weeks half-time work, i.e. 200 work hours per student

(includes all course related activities)

 

Rating of the impact of the project course on the market value of

graduates:

1 - low 5 - very high

 

==> 4-5 (qualified guess; no formal evaluations done, but positive

feedback from alumni)

 

Detailed Description:

 

What follows is a short summary of a recent paper that will soon be

published by the Journal of Computer Science Education.

 

The major goal of our project courses is to give students some

experience in non-trivial project work. Prior to our main project

course all students take a basic software engineering course which

comprises an introductory team project (5 weeks half-time work, 12-18

students per team). The main goal of this introductory project is to

make clear the major differences between individual work and working

in teams:

- Without planning, coordination, and commitments a team will most

likely not succeed.

- Individual top performances are not sufficient to succeed.

- Programming accounts for only a small fraction of the total work.

 

The main goal of the second (main) project course is to run a

non-trivial development project as professionally as possible. The

project spans all phases of one iteration of an object-oriented

development process. It starts with a problem definition and ends

with the (public) presentation of a running prototype.

 

A big problem with object-oriented development processes is that

they not as straightforward as, for example, traditional

waterfall-like models. In object-oriented development, there is no

clear border between analysis, design, and implementation. Students

therefore have difficulties deciding what to do when, how to do it,

and why to do it. Over the years we have developed a work-product

oriented development process to guide students through OO

development. This process was partly inspired by IBM's

Experience-Based Approach ([LiGu97]) and compares quite well with a

scaled down version of the RUP ([Kru00]).

 

A work-product oriented development process provides a framework

for structuring and managing object-oriented development. Development

can be defined in terms of interrelated work products. Each work

product is defined by its purpose and contents, the inputs needed,

and the techniques used to produce it. The definition of a

development process and the production of a single work product are

therefore more straightforward.

 

Students work in teams of 5-7 students. Among others, our course

design takes care of the following "misunderstandings":

- Requirements are the customers' responsibility. Our projects

start with more or less vague proposals. The student teams have

to contact the customers* for details and the customers have the

permission to change requirements during the projects. The

message is "it is YOUR responsibility to get the requirements

right."

- Up-front work does not pay-off. To make clear the importance of

careful design, clear specifications, and early development of

test cases, each team must subcontract another team for

developing a specific part of their own prototype.

 

Next fall this course will be offered for the ninth time. Up to

now 45 student teams (about 280 students in total) have completed

the course successfully. Although the course lasts only 10 weeks,

students are able to implement prototypes of significant size. Our

experience shows that a work-product oriented approach helps students

to organise and carry out their work.

 

The course evaluations show that students like the course. The design

of the course gives worthwhile insights into many new aspects of

their future work. Several alumni reported that the course very well

matched their situation at their workplaces. Many students comment

that teamwork was more difficult than they assumed, but that this was

an important lesson to learn. Students often complain about the heavy

workload and the amount of programming involved in the project, but

we think that a prototype must be built to validate analysis and

design.

 

For detailed information please check the course home page at

http://www.cs.umu.se/kurser/TDBC18/HT00/

for the latest offering (material in English is marked by a flag).

 

*Customers are usually local companies or staff not involved in

 

teaching this course.

 

References:

[LiGu97] Dave Livesey, Tom Guinane: "Developing Object-Oriented

Software, An Experience-Based Approach," Prentice Hall,

1997.

[Kru00] Philippe Kruchten: "The Rational Unified Process, An

Introduction," Addison-Wesley, 2000.

 

Dr. Jurgen Borstler phone: +46 (90) 786-6735

Department of Computing Science fax: +46 (90) 786-6126

Umea University e-mail: jubo@cs.umu.se

SE-901 87 Umea, SWEDEN URL: http://www.cs.umu.se/~jubo/

 

######################################################################

 

Title: Innovative Software Engineering Education

 

Authors: Professors Larry Bernstein and David Klappholtz

bernstein@worldnet.att.net, d.klappholz@worldnet.att.net.

Stevens Institute of Technology, Hoboken, NJ

 

Software projects often fail because the staff lacks Software

Engineering education or when they had it they fought it. To

compound the problem they don't accept Software Best Practices. Our

challenge is to overcome the natural biases of software professionals

and computer science students. Reading case histories of failed

software tends to convince some students of others' stupidity. While

other students intellectually accept the existence of the problems,

just reading about them does not convert many at the 'gut level.'

At the gut level one sits up, takes notice, and does something

different.

 

Motivation

 

Our approach is to force students to live through specific case

histories, each one chosen to get across a small number of important

issues. The method works. Students internalize the software

engineering lessons and follow best practices to avoid the traps they

experienced.

 

Here is how the approach works.

 

First, a set of software process issues is selected. Here are the

ones we chose for our first live-thru case history:

1. the need to have close customer/user relations

2. the need for up-to-date documentation throughout the life of the

project

3. the need to identify risks and to develop contingency plans

4. the need to account for human foibles

 

Second, a case history based on a project facing these challenges is

chosen. Students are not given the entire case history up front;

rather, they are given the same problem/project as the actual

developers who executed the case history faced. They are given no

more information about the problem/project than were those

developers. The project information is simplified to ease

understanding.

 

Background

 

Computer Science is the study of the technology (State-of- the-Art)

involved in the development of computer software. As it is usually

taught in a post-secondary setting, Computer Science deals with

"programming in the small," i.e., one-person or few-person software

projects. Software Engineering, on the other hand, is the study of

the method or process (State-of- the-Practice) whereby production

software is developed -- "programming in the large." State-of-the

-Practice includes both engineering practices and project management

or group dynamic processes. Many post-secondary programs in Computer

Science offer a Software Engineering or Senior Project course as a

capstone. Because of the very different natures of technology on

the one hand and method/process on the other, and because computer

science students are typically technology-oriented and method/

process-averse, the typical Software Engineering course reaches far

fewer future software developers than suits the best interests of

either the students themselves or the software industry at large.

We have developed a novel instructional method, the Live-Thru Case

History method for addressing this problem, have developed a first

live-thru case history, and have used it successfully in the first

few weeks of a two-semester undergraduate Software Engineering

course.

 

The result was that students were shocked into an awareness of the

Issues and how to deal with them in six weeks of two classes meetings

a week. One class meeting was devoted to project meetings and the

other to lectures on Software Engineering topics including other case

histories.

 

Conducting the Case History

 

Because there would be only one live-thru case history in our Senior

Project course, we had to choose one that would achieve the greatest

effect in the limited time available. We chose the case history of

a brief development project that one of the authors worked on, in

1985, as a public service project. The problem/project was that of

automating an elementary school library's manual system for

generating overdue-book notices.

 

The class of forty students was divided randomly into four equal-size

development teams. Students were given the same details, as were the

original software developers in the case history. The instructor

played the role of the customer, the school librarian, and was

available to students, to respond to questions, both in class and

by e-mail. Students were told that the customer would evaluate their

work, exactly as work is evaluated in the real world.

 

Results

 

As is frequently the case in real software development projects, the

Overdue book notice project had a hidden requirement that was so

obvious to the customer that she failed to mention it; it is that

overdue notices must be sorted, first by teacher name, then, for

each teacher by class, and, finally, within each class by student's

family name. The system analyst rejected the real software system

when she first saw it. The original developers failed to elicit the

hidden make-or-break requirement, and thus failed to satisfy it.

Each of the student teams fell into this same trap and they learned

the lesson of the need to find any 'hidden requirements.'

 

The need for high-quality documentation and for contingency planning

Were motivated for students by the classroom equivalent of the

real-world phenomenon of loss of staff members due to illness, death,

relocation, etc. At the midpoint of the project, the student from

each team judged, by the instructor, to be the team's strongest

developer and another, randomly chosen, team member were removed from

the team and re-assigned to a different team. To evaluate the

success of the staff change on students' approach to software

engineering, after the case study project students were then asked to

describe what they would have done differently had they understood

that the real-world conditions under which they would be operating

included the possibility of staff changes. About three quarters

of the students mentioned the importance of up-to-date documentation,

and about twenty percent had developed insight into appropriate

utilization of staff, including the use of "understudies" and of

preparation for the incorporation of new team members and thus

demonstrated that they had learned the value of these processes.

 

Evaluation of how well the students internalized the need for solid

requirements engineering was done the end of the live-thru case

history. A written exam was based on another case history. This

case history included a more difficult requirements engineering

problem than that of the overdue book notice project. About three

quarters of the students showed that they had mastered the notion

of hidden requirements, and about one third showed that they had

achieved reasonable competence in requirements engineering; about

ten percent showed extremely keen insight into the problem.

 

Claims

 

The innovative process of live-through case histories is more

effective than the traditional teaching of the Software Engineering

course. In the past students were given lectures, homework and exams

based on a well-respected Software Engineering text. Then they were

asked to develop a project. When they approached the project they

could not readily apply the techniques they learned. Once they

understood the need for the processes they re-learned them as they

tried to apply them.

 

Directions

 

The authors are asking those teaching software engineering to use

these case histories in their courses and report on the results.

Materials are available at web site www.NJCSE.org along with a

complete paper describing the live-thru approach in detail. Please

participate in gathering data to support or refute the claims in this

paper. It is our intent to use the experience of instructors in

several venues to make anecdotal conclusions more meaningful and

perhaps statistically significant. We invite those who agree with us

to join a consortium for the purpose of creating additional case

histories and helping to refine the process.

 

######################################################################

 

Title: Software Engineering Project Course at University of Hawaii

at Hilo

 

Author: John Gersting [johng@hawaii.edu]

Professor of Computer Science

 

Institution: University of Hawaii at Hilo

 

Summary Page:

 

The type of project course:

1. Industry involvement: yes (not-for-profit client)

 

The project course is taught at:

1. undergraduate level

 

The objectives of the project course:

- professional licensing concerns

- better prepare students for industrial projects,

- develop ability to work in a team,

- enhance communication skills and writing skills,

 

The project course is offered in the:

- general Computer Science degree

 

Project Workload:

-project is a part of a general Software Engineering course (two

semesters)

 

Ratint on the impact of the project course on the market value of

Graduates (1-low to 5-very high): 3

 

Abstract:

 

The Software Engineering sequence at UHH is a one-year (6 semester

hours) project-based course. It is one of two junior/senior

capstone sequences in the B.S. Computer Science degree (the other

is a database sequence). The objectives of the course are: better

prepare students for industrial projects, develop ability to work

in a team, and enhance communication skills and writing skills.

The project, which is a major part of a general Software Engineering

course, involved developing a 3-tier client / server web-based

application for an "outside, not-for-profit" customer. The Rational

Unified Process was used as the development methodology. The project

teams (3 to 6 teams depending on the iteration) were formed from

the 22 students in the class. The course was delivered partly in

a distance education mode (communication between sites used HITS-

Hawaii Interactive Television System and WebCT courseware).

Students were located on three different islands in the state of

Hawaii: the Big Island (17), Maui (3) and Oahu (2). The instructor

acted as the project manager.

 

Detailed Description:

 

The courses were run using a "workplace" metaphor. The students

played the role of a "new hire analyst" into a software development

shop. They had two basic missions, a training component where they

studied software engineering principles from text and lecture

material, and a work component where they participated in a team

developing part of the project deliverables.

 

The project development methodology followed the Rational Unified

Process (RUP) and was supported by the Rational Suite Enterprise

software. The RUP iterative development process involves four

phases, Inception, Elaboration, Construction and Transition. The

course project development involved five iterations: Elaboration 2,

Construction 1, 2, 3, 4 and Transition. The first two iterations,

Inception and Elaboration 1 - the requirements and specifications

in the form of a Stakeholder and a Vision document - were prepared

in advance for the start of the project.

 

The motivation for starting with Elaboration 2 (finishing the

specifications) was two-fold. Previous experience in this course

led to the conclusion that a great deal of "thrashing" occurred

in the requirements and specification portions of previous projects

while the students were introduced to the concepts of software

engineering through lecture material (design is hard). In previous

waterfall methodology courses, the requirements and specifications

consumed a semester; then when it was time for implementation to

begin, the documents that had been prepared were largely ignored

and final system integration was very difficult.

 

During Elaboration 2 the teams learned about the project in an

"actor-based" way, each team looking at the requirements and

features needed for the use cases for a given actor. The

deliverables were revised use case documents, a revised vision

document, and a Rose model including a database design. The system

architecture was 3-tier, IE browser, IIS, and SQL Server 7.0. The

middle layer was constructed using ASP for control and a DLL for

the database interface and generation of the HTML pages.

 

For each iteration, each team had a Team Lead. The Team Lead

interacted with the team members and the Project Manager on topics

such as task assignments and progress. Each team member submitted

a weekly time sheet based on his or her tasks. At the end of each

iteration the Team Lead wrote an evaluation for each member of his

or her team. Each student was a team lead sometime during the

project.

 

Construction 1 and 2 were dedicated to delivering a prototype for

customer evaluation. The construction teams were organized

around actor roles. A "daily build" process was started with

these iterations. System integration was not a difficulty at the

end of either of these iterations. The customer evaluated the

prototype at the end of the first semester.

 

The second course began with consideration of the customer

response to the prototype - a mini-elaboration iteration using

the same teams as Construction 2. This gave the students a good

introduction to feature creep. The deliverables were minor

revisions to some use case documents and the vision document,

and revision of the Rose model.

 

Construction 3 and 4 were to deliver the final product. The team

structure was changed to reflect the functional organization of

the Rose model. Code from the prototype was evaluated from a

reuse viewpoint and reorganized around functions (e.g., several

actors needed to write reports, hence the prototype contained

several ways to write a report; the best version was used in the

final construction). Construction 3 and 4 continued the daily

build process for the DLL - 90 builds were completed.

 

Transition consisted of a public presentation of the project to

the customer, completion of the documentation (on-line and hard

copy) and construction of a web site and database load for beta

testing by the customer.

 

At this point the students were "promoted" in the workplace role

to "managers". Now is the time to begin the Inception and

Elaboration for the next-year's project after the students have

been through their "training component" and functioned at the

"analyst" level in a project.

 

Ratint of the impact of the project course on the market value of

graduates:

 

Time will tell. Those students currently working in the field

have found previous versions of the course very realistic and

very helpful in their current jobs. The new graduates will be

tasked to "report back" after they have had on-the-job experience.

 

######################################################################

 

Title: An Undergraduate Software Engineering Project Course at UCSC

 

Authors: Donna Stidolph and Linda Werner [linda@cse.ucsc.edu]

Donna Stidolph (Graduate Student and Teaching Assistant) and

Linda Werner (Lecturer in Computer Science and Computer Engineering)

 

Institution: University of California at Santa Cruz

 

Summary Page:

 

Projects are formulated and conducted by a small number of faculty

members specializing in Software Engineering, with faculty members

and teaching assistants supervising student teams.

 

The project course is taught at the undergraduate level.

 

The objectives of our project course are

- degree accreditation concerns

- to better prepare students for industrial projects,

- to develop ability to work in a team

- to enhance communication skills and writing skills

- to enhance project planning skills.

 

Our project course is offered in the following degree programs:

bachelor of science in computer science, bachelor of art in computer

science, bachelor of science in computer engineering, and bachelor

of science in information systems management.

 

The project workload is part of a general software engineering

course. Our courses are 10 weeks long with 3 1/2 lectures hours per

week. The rating of the impact of the project course on the market

value of our graduates is 4 on a scale of 1(low) to 5(very high).

 

Detailed Description:

 

The Software Methodology course at UC Santa Cruz is a ten week

project course for seniors majoring in Computer Science, Information

Systems Management or Computer Engineering. Our goals are to enhance

students' ability to succeed in industry by introducing them to the

theory and practice of software engineering. To teach students about

the practice, we give them experience working in groups and working

within an externally imposed process. The emphasis in the course is

on the non-coding aspects of the software engineering process.

 

Students are formed into three to five person groups during the first

week of class. The groups then select a game to re-implement on a

computer, following a design/production process that we define. The

students are required to submit the following deliverables: a

requirements specification, a user manual, a paper prototype, an

architectural design, a detailed design, white box test procedures,

commented code with a coding standard, a functional system test plan

and procedure, and a formal Test Report.

 

The goal of the project documentation is to provide a consistent and

accurate view of the project across time. This means that all

documents are traced back to the preceding document, that the project

is sold off to the requirements documents, not the design documents,

and that multiple revisions of the documents are required.

 

Time, even more than is usually the case, is the major challenge to

making this class effective. Because of the ten week schedule, both

group and project selection must be done the first week of class.

In order to streamline group formation, at the first meeting, after

a brief introduction to the class, we have an "ice breaker" exercise.

The students form impromptu groups and assign a time keeper, note

taker, moderator. They then gather several pieces of information

about each group member: name, major, and skills/courses/work

experience of each person. The group then tries to assess together

what skills are needed for this class (tech writing, GUI coding,

etc.) and which of those skills are missing from the group as it

currently exists. This exercise helps students get to know one

another both on a personal level and on a professional level, and it

gives them practice running meetings - something that they will be

doing a lot of during the rest of the quarter.

 

After having them consider these things as a group, the students fill

out "getting to know you" forms, in which they state their major,

GPA, programming languages, whether they've had any technical writing

classes, and who they would like to work with. We, the professor and

TAs, then form the groups. If people elect to work with one another,

we always allow it. However, the intent is that the pre-questionnaire

exercise allowed the students to think about what they are getting

into, so that teams can be formed based on skill sets rather than

(or in addition to) friendships.

 

Once in groups, the students start project selection. We encourage

Them to select a simple game as a project. The overwhelming advantage

Of games is that the students can usually find one game that they

have all played and for which they can all agree on a set of rules,

thus reducing start-up frustration to a level that can be tolerated

in a ten week class.

 

Groups frequently select games too complex for the time, or too

Simple to support the weight of the documentation we're going to pile

on top of it. To address this problem, we require the students to

have both defining and distinguishing attributes for their games.

"Defining" attributes are those behaviors without which you haven't

done what you set out to do - a checkers game without crowning, for

example. "Distinguishing" attributes are what sets apart this

particular implementation of the game: an AI engine for a computer

opponent, or a history of high points players. The students are

directed to design so that all the attributes could be addressed, but

the game will be functional with only the defining attributes

implemented; that is, no defining attribute can depend on any

distinguishing attribute. Thanks to Brian Lawrence of Coyote

Software for the use of his requirements templates, which encourage

the prioritization of requirements.

 

We work with the groups to make sure that the overly ambitious groups

have a manageable set of requirements in their defining attributes;

and that the under-ambitious groups have several scope-extending

requirements in their distinguishing attributes. This has two

advantages. First, this allows requirements adjustments without

documentation rewrites, only negotiation. Second, it causes them to

think about what the fundamental requirements for the game really are

- good practice for the real world.

 

In the case of the under-ambitious groups, the "distinguishing"

attributes become a list of requirements enhancements we can levy on

them if, later in the quarter, we feel that they've bit off less than

they can chew. (We have done this as late as two weeks before system

test. Rather than change their functional test documentation, which

only addressed what they had planned to do, the students wrote an

Engineering Change Proposal, identifying areas of change in the

design and test documentation, reasons for the change, etc.

 

After games and groups are selected, the groups are given a week to

get organized. After that, milestones are due at a rate of one per

week until the sell-off demo on the last day of class. Each group is

required to have a notebook containing all the project documentation,

including group time logs and meeting agendas/minutes, and the entire

notebook is submitted for each milestone, so consistency checks can

be made.

 

To support this production rate, in addition to covering the topics

In class, templates for, and samples of, the documents are placed on

the class web site, and the grading sheets that the TAs use are made

available to the students to guide them in how to invest their

effort.

 

Since a premium is put on consistency but we want the documents to

reflect reality, we do not require that the students print out a new

version each time a document changes; we have implemented "redline"

control of the documents. In this scheme, documents can be changed by

hand-writing the change in the original document in ink, initialing

and dating the redline, and noting the change in the change log at

the beginning of each document. When the document becomes unreadable

(TA's decision), the updates are made as a batch and a new version

of the document is released.

 

Inspection techniques are covered within the first week, before

the first milestone is due. As soon as that lecture is done, one

group per class meeting performs an inspection of their current

milestone document for the class, for a significant portion of

their grade.

 

In addition to the milestone documents, there is an individual

homework assignment each week, but it's simple. On the first day of

class, the students are given ten minutes to answer the following

question:

"You've been at your current job for a week. Your boss has just

filled you in on what you're going to be doing - your job is,

according to him, to "improve" the GUI of the current product. He

tells you that the person you replaced had been working on it for

awhile, but just couldn't seem to get it right. The woman in the

cubicle next to yours tells you that the guy quit just before he

got fired, and you are the third person hired to make this

'improvement'. What do you do? (Quitting is not an option - you love

the espresso machine.) Use your knowledge of software engineering

tools and techniques to guide you."

 

Each week, each student is asked to take ten minutes and answer the

question again, in light of what they learned the previous week.

 

The most frequent problem we've encountered is group grading. There

Is only one individually graded milestone, all the others are group

efforts, and every quarter there is a group that has problems with

equitable distribution of work or effort. Most groups ask the TAs or

the professor to help them work through the problems, but we also

offer an alternative grading scheme. Unless otherwise directed, all

group members get the same score on all milestones. However, as an

alternative, group members can submit "votes" on how much each member

contributed. We take that input and average it with all the other

inputs (assumed to be equal if people don't vote) and use that to

allocate the individual scores. Since it is an average, one

disgruntled group member can't move the numbers very much, but if

two or three people feel someone is taking advantage, they can affect

the grade significantly.

 

We are a relatively small engineering school and we only allow

seniors in the class. As a result, it's not unusual, at some point in

the quarter, to have all the members of a group working on a project

for another class. Since we are a time sink for the entire quarter,

we feel that we should provide the flexibility so that this isn't

catastrophic. Each group is allowed to submit one milestone up to a

week late with no penalty, but they must tell us three days in

advance. This has no effect on the next due date for the next

milestone - they'll have to submit two the following week, but it

gives the students some control over their time and doesn't force

them to make an either/or choice about what project to do.

 

Students come to the class with differing levels of preparation. We

attempt to combat this by pointing out the skill sets needed for a

group to succeed. Frequently, though, the problems are caused by

inexperience in time budgeting with group projects, not by any lack

of technical skill. On average, one group a quarter gets into

trouble. If the class size supports it, the TAs can intervene by

working through the next milestone with the team, by requiring daily

status reports via e-mail, etc. However, not all problems can be

addressed.

 

Plans for the future include requiring a section for upward

compatibility with a "Common Game Manager" for all the games. At the

requirements level this would require all the groups agree on a

common user interface standard, so the games all looked the same; and

that they select some method to ensure that the games can be

integrated: common language, common IDE, etc.

 

Linda Werner, Ph.D., Lecturer

831 459 4953 (w)

831 427 2076 (h)

831 459 4829 (FAX)

Computer Science and Computer Engineering Departments

157C Baskin Engineering

University of California, Santa Cruz, CA 95064

http://www.cse.ucsc.edu/~linda

 

######################################################################

 

Title: A Software Project Course at Norwegian University of Science

and Technology

 

Author: Letizia Jaccheri letizia@idi.ntnu.no

Institution: Department of Computer and Information Science,

Norwegian University of Science and Technology, Trondheim Norway

 

Summary Page:

 

The type of your project course:

 

1. Industry involvement: no

2. Projects proposed and supervised by faculty members in areas of

their expertise: no

3. Project(s) formulated and conducted by a small number of faculty

members specializing in Software Engineering, with faculty members

and teaching assistants supervising student teams: yes

4. Other: please describe

 

The project course is taught at:

1. undergraduate level: yes 4th year

2. graduate level: yes, graduate students may choose this course as

well.

 

The objectives of the project course:

 

- better prepare students for industrial projects,

- develop ability to work in a team,

- enhance communication skills and writing skills,

- enhance project planning skills,

- other objectives - experience the difficulty of changing existing

systems, experiment with architecture issues, work with

alternative designs for the same system.

 

Project course is offered in the:

1. general Computer Science degree: yes, all students can choose it.

2. Software Engineering degree: yes, it is mandatory for software

engineering students.

3. other - please indicate.

 

Project workload:

1. project is a part of a general Software Engineering course:

yes. The project has a workload equivalent to 1/2 of a

full-fledged project course.

2. full-fledged project course with workload equivalent to: for

example, a typical 1 term course (13 weeks, 3 lectures per week)

 

Rating of the impact of the project course on the market value of

Graduates(1-low to 5-very high): 4

 

Detailed Description:

 

I have been teaching for the first time a course in the field of

software architecture during Spring 2001. The educational goals of

the course are the following. First, let students get acquainted with

methods about architecture evaluation and change, software design

styles and patterns, and domain specific architecture. Second,

students must experiment with architecture issues, e.g., evaluate and

choose alternative designs for the same system, apply patterns, and

above all, experience the difficulty of changing software rather than

build it from scratch.

 

The course is built around a project. Concerning the industrial

involvement in the project, I designed a project which emphasizes

application of best practices and principles in the field of software

architecture without any emulation of real-world (hilburn2001). The

only involvement of real world actors consists of three guest

lectures from industry. In fact, students which attend this course,

have experienced during the previous semester a big project course

which has the main goal of letting them experience the interaction

with a real customer. So, it is a choice to create an environment

in which students concentrate mainly on architecture issues.

 

The project process definition and rules are simple. Input to the

project are existing methods and tools for deriving architectures

from requirements (such as RUP and rational rose), methods and tools

for architecture analysis and transformation (Bosch2000), and the

eCourse system. eCourse (ecourse2001) is a running support system for

document exchange as BSCW (bscw2001) which has been developed before

course start and which comes together with its requirements,

architecture, design, source code, and test, etc. eCourse is a small

system (100 classes and 6000 lines of Java code).

 

Students view the system eCourse both from a developer and a user

perspective. Students will implement both changes to improve the

architecture with respect to quality attributes (maintenance,

performance, usability) and maintenance changes.

 

Every student will use eCourse to access and exchange

documentation. Documentation includes slides from the teacher, all

documentation about eCourse itself (requirement, design, etc.) and

its subsequent versions.

 

There are 10 groups, each group having 6/7 students. The maintenance

group is responsible for correcting major bugs, as well as evaluating

if and which subsequent versions of the system shall be taken in use

This group will be stable over the whole semester. Then, we have 3

test groups, 3 architecture groups, and 3 implementation groups. The

test groups are responsible of both improving requirements and

evaluating architecture and testing the final systems. The architect

groups are responsible of transforming the architecture. The

Implementation groups will change the code.

 

For each phase, there is one group who is in charge of working with

performance, one group who works with maintenance and one with

usability. We could have chosen other qualities such as reliability,

safety, and security. Our choice is pragmatic and we may choose other

quality attribute combinations in future runs of the course.

 

Each phase lasts three weeks, so the project spans over the whole 13

weeks semester. Here, for each phase, we list phase name; responsible

group; and deliverables:

 

* Improve requirements and Evaluate architecture; Test group;

Scenarios for non functional requirement and Architecture

evaluation.

 

* Transform architecture; Architect group; New architecture, new Rose

models.

 

* Change implementation; Implementation group; New system.

 

* Test; Test group; Test report.

 

* Maintenance; Maintenance group; Change report.

 

All documents are delivered using eCourse. Each deliverable contains

a small evaluation of the phase and reports about how much time was

spent. Each deadline is associated to a one hour presentation in

classroom per group.

 

We are now in the process of analyzing project data to assess our

pedagogical and research goals. Students have been working hard. The

presentations and discussions in class have been interesting for both

students and teachers. Students have reported a total amount of 1161

worked hours. This time effort has been divided as follows: 250 hours

for Improve requirements and Evaluate architecture; 423 hours for

Transform architecture; 305 hours for Implementation; 183 hours for

Test.

 

References:

(Bosch2000) Design & Use of Software Architecture, Jan Bosch, 2000,

Addison Wesley.

(eCourse2001) The eCourse system, ada11.idi.ntnu.no/ecourse.html,

(In Norwegian).

(bscw2001) BSCW (Basic Support for Cooperative Work) home page,

http://bscw.gmd.de/

(hilburn2001) So Let's Make That Software Project Course Real World,

Tom Hilburn, FASE April 2001.

 

######################################################################

 

Title: A Software Engineering Project Course at the University of

Texas at Austin

Author: Vicki L. Almstrum [almstrum@cs.utexas.edu]

Institution: Department of Computer Sciences, Univ. of Texas at

Austin

 

Summary Page:

 

The type of your project course:

Projects formulated by instructor in collaboration with "clients" in

the community and in other parts of the university. Teams supervised

by instructor and teaching assistants, with participation by up to

two mentors from industry per 5/6 person team. There are 10 to 15

teams per semester.

 

The project course is taught at:

1. undergraduate level

 

The objectives of the project course:

- better prepare students for industrial projects,

- develop ability to work in a team,

- enhance communication skills and writing skills,

- enhance project planning skills,

 

Project course is offered in the:

1. general Computer Science degree (as an elective)

 

Project workload:

1. project is a part of a general Software Engineering course

 

Rating of the impact of the project course on the market value of

Your graduates (1-low to 5-very high):

4 - high

 

Detailed Description:

 

This past academic year was the fourth year I have taught this

Software engineering course. Enrollment this spring semester was 88

Students across three sections. The practical side of the course

Emphasizes creating genuine projects for real clients. Full

information about the course can be viewed via the URL

http://www.cs.utexas.edu/users/almstrum/classes/cs373/. I have also

described the course in the article "A Course with Service-Oriented

Project Work" (FASE, August 1999). In the remainder of this

article, I discuss a number of issues that illustrate how I try to

make this course realistic. I feel it is vital to incorporate real

world experiences. Every team works with a real client and must

communicate directly with the client to understand the true

requirements. Every team produces a series of documents that must

meet the class documentation standards, which are based on industry

standards. I match each team with up to two outside mentors,

professionals from industry who advise the team and provide comments

on the team's work products.

 

Students may not enroll in this course until they have completed the

Core courses in the CS curriculum. Most are seniors, with the most

of the rest juniors and an occasional graduate student. As part of

becoming acquainted, the teams must assess their own skill sets.

Once assigned a project, each team must plan for how to acquire any

additional technical skills they will need for their projects.

During some in-class lectures, we discuss key commands for using

Unix, CVS, and other development tools. The teaching assistants for

the course lead discussion sections early in the semester, where

they give more detailed presentations of the commonly used support

tools. The class web site includes links to on-line resources,

which assists students in discovering some of their own answers

from among options that have been used in earlier semesters.

 

Because this course is a substantial writing component, I assign

individual writing exercises where each student develops his or her

personal writing ability. The teams' project documents are not

appropriate for individual evaluation because I give each team

freedom to delegate tasks as they prefer. In one of the individual

writing assignments, each student reviews two projects from earlier

semesters (as assigned by me) and writes a report based on their

findings. The students complete this assignment early in the

semester, which helps them become familiar with the general structure

of these projects much sooner than they otherwise would. The

students' results also provide feedback on needed improvements for

these older projects.

 

In order of occurrence of initial versions, the main project

Milestones during the semester are:

* the Project Bid (the basis for assigning projects to teams; the

allocation of projects is competitive and no two teams work on

exactly the same project; some projects are new developments and

some are extensions of projects from earlier semesters)

* the Project Plan (an initial snapshot of the team composition,

plan for approaching the project, team procedures, etc.)

* Software Requirements Specification

* Preliminary Software Design Specification

* Mid-semester in-class presentation of team and project (done in

a professional setting using computer and projection device; all

students comment on sticky notes as each team presents; the notes

are stuck onto team-wise posters on the wall as everyone leaves

and the posters taken immediately by the teams; the instructor

scribbles observations on a prepared rubric in order to give

very quick and somewhat detailed comments to each team)

* Detailed Software Design Specification

* Mid-term mutual evaluation (each team member evaluates everyone

on the team, including them self; the results go only to the

instructor, who returns individual summaries and suggestions for

improvement to each team member)

* Verification and Validation Plan

* Alpha version of project, with audit of the project by the

teaching assistant (and verification by the instructor)

* Verification and Validation Results

* Beta version of project, with audit of the project by the

teaching assistant (and verification by the instructor)

* Final in-class presentation of project (similar to the mid-

semester in-class presentation, except most teams now demo

their nearly completed projects)

* Final version of project

* Client Release Presentation (at the client site)

* Final mutual evaluation (essentially the same as the mid-term

version except the results from this version are used to

determine 15% of each student's final grade)

* Legacy Turn-in Meeting (an hour-long meeting where the team

presents the instructor with a notebook that includes final

versions of all documents, team reports, and other information

that would be useful as a future team begins to understand the

project for modifying or extending it; the team leaves the

meeting with a list of action items to complete in order to

finalize the project)

 

While the schedule of milestones is pre-defined, I remain very

flexible in allowing teams to slip most milestones. They must

request the slip formally (via email), they must motivate the slip,

and they must assure me that the slip will not adversely affect the

remaining milestones. I generally grant all requests for slips.

Essentially every document is submitted at least twice. I do not

always find the time to return feedback on later versions of the

documents but expect that the mentors will continue to review all

versions for content and consistency.

 

This course is very demanding of the instructor and teaching

assistants. We divide the evaluation tasks to the extent we can. I

personally provide detailed feedback on each team's initial version

documents and, as time allows, on later version documents as well.

In my comments, I emphasize the importance of following standards and

interpreting the various sections in a way that is consistent with

intentions. Each teaching assistant is associated with a specific

section of the class, which allows him or her to focus on a maximum

of five teams. The teaching assistants meet with each team at least

three times through the semester; the agenda of the meeting is set by

the team to make the time as useful as possible. When the teams turn

in the alpha and beta versions of their projects in the latter part

of the semester, the TAs conduct an audit of their teams' projects,

using a pre-published checklist of concerns that address how well the

project conforms to standards and whether the product runs well. I

meet with teams during in-class meetings periodically during the

semester; these brief meetings help me assess how each team is doing.

The key meeting between me and the teams is at the end of the

semester, during which the team turns in their legacy notebook.

Together, we walk through their collection of materials about the

project, assigning action items to complete in order to finalize the

project before transfer to me. During the meeting, we use a

projection device connected to a computer linked into the

departmental network, which makes it possible to inspect the team's

final repository and make quick adjustments and corrections on the

spot.

 

Teaching this course has been very rewarding. Through regular

Individual journal entries (about four per semester), I receive a

great deal of feedback from students. This feedback helps me adjust

the course both during the semester and between semesters. The

feedback also helps keep me energized, as I quickly see the effect

of what I am doing. The course has the reputation among the students

as one that requires hard work but provides excellent return on that

investment; they like seeing software engineering from both the

theoretical and the practical side. Balancing these factors in

setting up the course is a tricky task. Two approaches we have

considered to improving the work load of the course for everyone

would be to either make it a two-semester sequence (first semester:

theory plus writing component; second semester project-focused) OR do

away with the writing component aspect (and thus remove the need for

carefully evaluated individual assignments). At this point, no such

modifications are imminent.

 

Vicki L. Almstrum, Ph.D tel: +1-512-471-9737

Dept of CS, TAY 2.124 (C0500) +1-512-471-7316 (dept. switchboard)

Univ. of Texas at Austin fax: +1-512-471-8885

Austin, TX 78712 USA email: almstrum@cs.utexas.edu

office: TAY 4.118 http://www.cs.utexas.edu/users/almstrum/

 

######################################################################

 

Title: Real Software Engineering Projects at the University of

Sheffield

 

Author: Mike Holcombe [m.holcombe@dcs.shef.ac.uk]

Professor of Computer Science and Dean of Engineering

University of Sheffield

 

INTRODUCTION

 

Teaching computer science and software engineering students is

greatly enhanced if they can be introduced to the real issues

relating to software design through the mechanism of projects for

real business clients. For more than 10 years we have required

students to take part in team projects in their second year where

the teams compete with each other to produce a solution for a

business person's current problem. Each student is required to work

for 100 hours on this project during the semester. This equates to

9-10 hours per week on the project for each student over 12 weeks.

Typically there are 80 students in the class and there are three

business clients each with a specific problem relating to their

business. The student teams are each allocated to one of these

clients. The teams comprise 5 students and each client deals with 5

or 6 teams. At the end of the Semester the client evaluates all of

the software solutions produced and selects the best one for use in

their organisation. The winning students receive a prize. This

framework really transforms the students' learning because it

emphasizes two of the most problematical issues when teaching

software design, how to communicate with a client and capture the

real requirements and how to deliver a really high quality, bug free

system. It is very hard to introduce either of these dimensions into

the curriculum using projects specified by academics. Students know

that once the software has been marked it is usually thrown away.

With our approach, which we call the Software Hut, students are much

more motivated because they know that someone wants their work and

will use it. They also learn quite a lot about the way businesses

work. It is always the most popular course and the one that they say

teaches them the most! More details can be found in [1] and [3]. A

recent extension of this approach occurs in the 4th year where the

students run their own software company and spend approximately one

third of their time working in it. The company, they call it Genesys

Solutions, [2] and [4] (formerly called VICI), has a wide variety of

clients requiring database systems and e-commerce applications. About

25 students work in the company. The students run the company, take

all major decisions, operate their own premises and network, and

carry out R & D as well as specific industrial projects. As part of

this the students negotiate the details of a contract with a client

- cost, delivery as well as the detailed requirements specification.

As one might expect, estimation and planning is a major issue in

running the company and one of things that we are trying to do is to

collect suitable data on projects that would help us to do this

better. We believe that this student-run company is a unique

innovation but one which the students are incredibly enthusiastic

about. As an aside, a number of former members of this company have

successfully set up their own real software houses.

 

THE SOFTWARE HUT

 

I introduced the Software Hut course 12 years ago, it was completely

novel, no other courses like it were being taught in the UK. It

introduced second year students to a realistic experience of working

in a software house. It was different to all other courses because it

involved a real external client who wanted software solution to a

real business problem. This introduced students to two fundamental

issues that cannot be addressed in any other way:

1. the problems of negotiating with a client who may not know what

they really want,

2. the responsibilities of producing a high quality solution that can

be used successfully in the client's business.

 

These issues are at the heart of software engineering and are rarely

dealt with satisfactorily in the theoretical confines of a computer

science course.

 

Of course, some universities encourage or require students to take

placements in industry, this is sometime valuable but the experience

can be very varied and may still not address the fundamental two

points identified above. All the research we have carried out clearly

indicates that the in-house (i.e. on campus) real client experience

is the best learning environment since we can ensure that the very

best and latest professional practice is experienced by the students,

something that would not be the case in many industrial placements.

 

As I will indicate later this experience develops students skills and

understanding in a way that is demonstrably superior to that provided

by standard curriculum Computer Science found at ALL other UK

universities.

 

The Software Hut comprises around 90 trainee software engineers and

three senior managers. Typically it produces three real systems each

year for real clients from business companies and other, public,

organisations. The core business expertise of the company is bespoke

databases with custom front ends and web based applications, usually

with an e-commerce aspect. The mode of operation of the company is to

have one third of the members working with each client. Within this

division into sections there are 6 teams of 5 developers each of

which build a version of the product in competition with the others.

The clients choose the best system from the 6 produced and these are

used in the client's organisation. The IPR is negotiated separately

for a fee. What this means is that there is an opportunity to use

different design approaches with the different teams and this can be

the basis of a detailed scientific comparison of different

approaches. Currently the company is planning to operate with the

next projects an experiment whereby one set of teams applies

"standard" software engineering methods based around UML and a

significant design and analysis phase. The other set of teams will

use the extreme programming approach - a lightweight, test driven

approach. We hope to collect and analyse some data from this exercise

to see if there is a significant difference in the performance of

the teams and the quality of their products.

 

GENESYS SOLUTIONS

 

With the assistance of the FDTL grant I introduced the 4th year

Student software company as a natural development of the 2nd year

Software Hut. Here the students own and run the company, doing real

Projects for their clients and using their own premises that I

arranged for them. This is the Business Incubation Laboratory, which

is completely managed by the students,. They purchase their equipment

from their earnings and install and administer it all, it is run

independently of the University, the students are fully responsible

and as such have developed a highly professional infrastructure and

arrangements which would be a credit to any major software company.

 

Genesys Solutions is a partnership of 25 qualified software engineers

carrying out a similar range of contracts but also providing

consultancy and other services. The company has its own R & D section

and provides infrastructure support to the design process. The way

that this company will be used will be to consider how the results

of the comparative evaluations of the methodologies and processes

derived from the Software Hut experiments can be introduced and

embedded into an existing software house. This is an important area

because of the apparent reluctance of many software companies to

introduce new methods of working.

 

All clients of these companies will be asked to permit the results of

these experiments to be published. In the past a number of the

projects carried out by these companies have been the basis of

publications and so far all the clients have been happy with this

- provided any "in confidence" commercial details are hidden. It is

very difficult to persuade software houses to release the results

of any analysis of their design projects because of commercial

reasons.

 

THE SOFTWARE OBSERVATORY

 

Since software development is a rapidly changing industry the

introduction of new methods, tools and languages is likely to

continue, we need a mechanism for evaluating the latest ideas in

realistic situations. I have developed the two activities, the

Software Hut and Genesys Solutions into a framework for research into

empirical software engineering which I am calling the Software

Engineering Observatory. The aim of this is to use the activities of

these students projects as a basis for fundamental research into the

construction of software and to provide insights into how it might be

done better for the benefit of the software engineering industry.

This is an example of teaching activities supporting subject based

research. Once the observatory has been established it will be able

to provide a service to the software industry based around realistic

and rigorous scientific approaches to the evaluation of different

methodologies and processes over a long term. The Observatory will be

reactive to new methods and technologies and receptive to new demands

from clients. The students involved will benefit from exposure to the

latest ideas and will feel part of an important contribution to the

improvement of their subject.

 

During the course of the Software Hut projects each team generates

between 200 and 300 pages of documentation, this includes

requirements documentation, detailed designs, source code, test sets

and results, debugging reports, quality review reports, time sheets,

meeting minutes and team evaluations. The source code is typically of

the order of 10 000 lines of code for the sort of systems built. The

clients and managers also produce reports on the products delivered

and evaluated as well as the judgments on the design processes.

 

This documentation, taken over 18 teams and archived over several

years so far, provides us with a major resource for the analysis of

many aspects of the investigation. This is how the work leads into

real research into empirical software engineering.

 

AN EXAMPLE

 

The Observatory team will define a number of experiments each year

based around the use of the Software Hut and Genesys Solutions

projects. These experiments will be carefully designed and suitable

clients and projects obtained to act as the focus of the experiments.

The framework and facilities required will be set up by the

Observatory team, this will include suitable tools, repositories and

appropriate recording software and techniques. The definition of the

metrics and other evaluation techniques that are to be used will be

done before the experiments begin. The training of the student teams

in the appropriate technology and facilities will be carried out

under carefully controlled conditions. Since all clients pay for

their solutions there is an important motivational driver for the

student teams and this has always ensured that the teams are

appropriately motivated.

 

Key activities will include the estimation by the teams of the

resources needed for their projects and this will be done using

appropriate methods - in fact estimation techniques could be a

particular focus of some experiments as well as risk analysis and

planning techniques. Other suitable metrics such as object point

analysis, weighted methods per class, as well as measures of software

quality will be available. The time spent per team, per team member

and how it is spent are also important factors that will assist in

the analysis of the efficacy and expense of any method. The

relationships between all these variables will be major areas of

interest. This semester (February 2001) sees the start of the next

Software Hut exercise. There are, as usual 3 clients each dealing

with 6 teams and what we plan to do is to divide the 6 teams into two

groups, one of which will be given some reinforcement in traditional

software design techniques and the other will get a crash course in

Extreme Programming. We will then monitor the progress of the two

cohorts of students, some using XP others not, as they attempt to

build their solutions. This will be done by studying the way they

manage their projects. Each team has to produce and maintain

realistic plans, keep minutes of all their project meetings, and by

interviewing them weekly. We will also get all of their working

documents, requirements documents, analysis, test cases, designs,

code and test reports. These will provide many further opportunities

for measuring attributes of their output, ranging from function and

object point analysis to bug densities.

 

At the end of the Semester, the clients evaluate and mark all the

Delivered solutions, they use a structured marking scheme that we

construct for them and this provides a final level of measurement

relating to how well the solutions did - usability, installability,

functionality, robustness etc. These are the key attributes since

they will be applicable to all the solutions no matter how built.

We will use this information in a statistical analysis to see whether

there are any significant differences in the quality of the final

products between XP and traditional "heavyweight" methods. Finally

we will require each student to give both a team evaluation and a

personal commentary on how the project went, the strengths and

weakness of what they did and how they did it. In the past this has

proved to be very useful in identifying issues and problems with

approaches to software development. After delivery we will be able to

track the performance of the delivered systems to gain further

information about their quality in their working environment. The

three clients are as follows (see Figure 1.): Client A is a small

start up company in the Bioinformatics industry requiring software

for data analysis. Client B is a legal practice centre, that requires

computer based training software for the legal profession. Client C

is an organisation which brokers waste and wants a web based system

that interfaces to the existing database and allows clients the

opportunity to browse the database.

This is just the start. We are bound to see, as software engineering

evolves, the emergence of different ways of doing it, using different

tools, methods and notations. This will give us further opportunities

to test out the ideas in our Software Engineering Observatory: the

Software Hut for detailed comparative experiments and Genesys where

we are investigating how new ideas and methods can be introduced into

a working software company.

 

EVALUATION AND DISCUSSION

 

One of the most important results from the work that has been done so

far is the reaction of both the students involved and of employers.

It has been entirely positive, we always ask each student to write a

reflective self evaluation of their experience in both the Software

Hut and Genesys. These always emphasis how valuable the experience

as been and how it has developed a great awareness of the industrial

context of software engineering, how it has put into perspective much

of the work that they have covered in other courses and how it has

given them a lot of self confidence and the skills to work in a high

quality professional design environment. The fact that they have to

document their work, their meetings and the time that they spend

carefully and in a standardised format has helped them to adjust from

the rather chaotic and disorganised atmosphere of university student

life to one of an enthusiastic and highly organised professional.

very student remarks that at interviews these courses are the only

ones that the companies want to talk about, they are often amazed

at what the students have achieved. This is confirmed by our own

interactions with employers through the Department's Industrial

Liaison Board and on other occasions. Many of the top employers are

now targeting the Department because of its reputation. In the

Software Consultancy business, for example, the principal focus of

graduate training programmes is the relationships with the clients.

This is something that my students have been heavily involved with,

unlike any other university graduate! They thus have a major

advantage over their competitors.

 

Every year I carry out an in depth interview with each member of

Genesys just after the end of the 1st Semester. This is essentially

formative but it also allows me to assess the way the course works at

the half way stage. This year the class consists of 15 MEng students,

(4th year students who have spent the previous 3 years in the

Department, these students have done the Software Hut in their 2nd

year); and 10 advanced MSc students, who have graduated with good

Computing degrees from other universities. None of these MSc

students have done anything like the Software Hut, some have done

group software design projects but all have commented that these were

not taken seriously. The contrast between the two cohorts is nothing

short of staggering. The MSc students have found it very hard

adjusting to the fact that they have much more responsibility for

their own learning and for the management of their projects. None had

ever met a client before and were extremely nervous about the

prospect. None had really had to manage a serious group project

before, either. There was a very marked difference in the attitudes

when it came to the need to learn some new technology, the Sheffield

students immediately got on with it and helped each other to master

the complexities of the material whereas the MSc students immediate

response was to ask for courses in the material. Their ability to

direct their own learning was not very impressive. Luckily, the

Sheffield students were able to help them by giving them short

courses in the material. The Sheffield students also insisted on

wanting to run the company themselves, taking full responsibility for

all decisions and for managing their projects, the MSc students, on

the other hand, wanted much closer management from me and my

colleague, telling them what to do to a much greater extent.

 

This seems to be impressive evidence that the Software Hut is

extremely successful in developing the lifelong learning skills and

confidence that are needed in such a dynamic business as the software

industry. The question remains of why these approaches are so unique,

they have received a considerable amount of publicity in the national

computing press and at many conferences and workshops. The only UK

universities where anything like the Software Hut has been introduced

are Leeds and Leicester who both started up a second year group

project modelled on it last year 1999-2000, although neither have

real clients, the lecturer running the module is the client, a factor

that I believe seriously weakens the exercise but may be an interim

feature. Whenever these courses are discussed at meetings the

standard response of academics who would like to set one up is that

it would not get through their quality assurance process. They say

that concerns about the control of the outcomes, the assessment

process and similar issues would prevent their receiving approval.

This is just one example of the way that fear of the QAA assessment

process has prevented truly innovative developments in teaching and

is to be thoroughly deprecated. The unpredictable attitudes of QAA

assessors is the main reason for this problem, although the recent

accreditation by the British Computer Society of the Department's

degrees was extremely favourable and great praise was made of both

the Software Hut and Genesys, so perhaps times and attitudes are

changing. The reasons why both Leeds and Leicester have developed

their courses, despite these fears, might be related to the fact that

I am currently their external examiner!

 

References

1. A. Stratton, M. Holcombe and P. Croll "Improving the quality of

software engineering courses through university based industrial

 

projects." in "Projects in the Computing Curriculum", (eds.) M.

Holcombe, A. Stratton, S. Fincher, G. Griffiths, Springer, (1998).

47-69.

2. M. Holcombe and A. Stratton. "VICI: experiences and proposals for

student run software companies." in "Projects in the Computing

Curriculum", (eds.) M. Holcombe, A. Stratton, S. Fincher,

G. Griffiths, Springer, 103-114.

3. with Helen Parker, "Keeping our customers happy: Myths and

management Issues in Client led student software projects."

Computer Science Education, 9 (3), 230-241, 1999.

4. Genesys Solutions Web site, On-Line at

<http://www.genesys.shef.ac.uk/>

 

######################################################################

 

Title: Software Engineering Project Course at Gannon University

Author: Steve Frezza [frezza@gannon.edu]

Institution: Gannon University

 

The type of your project course:

1. Industry involvement: NO (not typically)

4. Other: please describe

Projects formulated by students, directed by students under faculty

supervision

 

The project course is taught at:

1. undergraduate level

 

The objectives of the project course:

- better prepare students for industrial projects,

- develop ability to work in a team,

- enhance communication skills and writing skills,

- enhance project planning skills,

- Enhance project specification skills

 

Project course is offered in the:

- general Computer Science degree

- Electrical Engineering (Embedded Software Engineering Track)

 

Project workload:

- project is a part of a general Software Engineering course

 

Rating of the impact of the project course on the market value of

Graduates (1-low to 5-very high):

4 - Moderately High (SWAG, based on oral feedback from students and

their job hunting)

 

Two issues we've attempted to address in our undergraduate Software

Engineering project course are the issues of student motivation and

team formation. While the projects are structured to walk students

through the process of formulating, designing, implementing, testing

and delivering a product, these are relatively difficult issues to

manage without attaining strong student commitment to the projects

themselves. In particular, students have little experience

formulating problems for others to solve.

 

Our method for encouraging high levels of student motivation include

a competitive proposal process that allows students to competitively

propose ideas (scoped to fit within the bounds of the course), and to

form teams around the projects based on their interests. These

projects and teams are scoped to be small (2-4 students) to ensure

the ability of the students to deliver their project at the end of

the semester.

 

The caveat to the proposal/team formation process is that students

are not allowed to work on projects they personally proposed: thus

the students of one team are organized to be the functional owners

(customers) for another team. Thus they serve as interested (and more

importantly _available_) customers who do not always have clear ideas

of what they want in their product. Since it is a team of functional

owners, there are ample opportunities for real miscommunication among

the requirements stakeholders. This means the development team is

necessarily faced with the issues of requirements change, ambiguity,

etc. that are very real, but typically tractable.

 

This course is a follows a design and testing course, so specific

areas of focus include requirements, project planning, risk

management, estimation, tracking, product quality, teamwork and other

social aspects.

 

Stephen T. Frezza, Ph. D.

Assistant Professor, Electrical & Computer Engineering

109 University Square, MB 3181

Erie, PA 16541

Voice: 814-871-7563

FAX: 814-871-7616

email: frezza@gannon.edu

URL: http://www.ecs.gannon.edu/~frezza

 

######################################################################

 

Title: Software Engineering Project Course at California State

University, Sacramento

Author: Richard H. Thayer [thayer@csus.edu]

Institution: Californian State University, Sacramento

 

Summary page:

The type of your project course:

1. Industry involvement: yes

2. Projects proposed and supervised by faculty members in areas of

their expertise. Yes and no. Groups of student teams are assigned to

faculty members. Most of the faculty members are experts in SWE but

not necessarily in the application.

3. Project(s) formulated and conducted by a small number of faculty

members specializing in Software Engineering, with faculty members

supervising student teams.

 

The project course is taught at the undergraduate level

 

The objectives of the project course:

- degree accreditation concerns

- better prepare students for industrial projects,

- develop ability to work in a team,

- enhance communication skills and writing skills,

- enhance project planning skills,

- other objectives - please describe.

- Give them some real-world experience to put on their resume

- Make contact with industry that might be hiring

- Summarize everything they have learned to date

 

The project course is offered in the:

- general Computer Science degree

 

Project workload:

- full-fledged project course with workload equivalent to:

two semesters (15 weeks each) 2 credits per semester ( 1 hr lecture;

3 hour lab)

 

Rating of the impact of the project course on the market value of

Graduates (1-low to 5-very high):

5 - very high

 

Richard H. Thayer

Professor in Software Engineering

Department of Computer Science

California State University, Sacramento

Sacramento, CA 95819-6021

Home Tel: 916-481-5482

Home Fax: 916-481-8778

 

######################################################################

 

Title: Using Critical Essays in a Project Course

Author: Sally Jo Cunningham [Sally.Cunningham@zu.ac.ae]

Institution: University of Waikato (New Zealand)

 

Summary page:

 

Industry involvement: yes

 

The project course is taught at undergraduate level.

 

The objectives of the project course

- better prepare students for industrial projects,

- develop ability to work in a team,

- enhance communication skills and writing skills,

- enhance project planning skills,

 

Project course is offered in the 'Information Systems' programme of

a computer science degree.

 

Project workload:

- full-fledged project course with workload equivalent to:

one full New Zealand semester course (12 weeks, 4 lecture hours

per week)

 

Rating of the impact of the project course on the market value of

Graduates (1-low to 5-very high):

5 - very high

 

Detailed Description:

 

I teach a course formally titled 'Information System Development',

in which students work in groups of 4-6 to develop a prototype of a

system suitable for a local business. Each group works on a different

system.

 

The project is the basis for all assessment in the course, and the

students within a group receive the same grade for the various

'deliverables' associated with their group's project. There is no

test, as the course is designed primarily to support students in

applying skills learned (or rather, hopefully learned) in

prerequisite courses, rather than to cover new theoretic material.

 

University regulations, however, require that at least 30% of each

student's assessed coursework be 'demonstrably the student's own

work'. To that end, the students also receive individual grades for

essays that they write, critiquing the work of *other* groups. For

example, one group deliverable involves designing the user interface

for the system. Each person in the course must read through a

different group's design description and write a brief (2-4 page)

discussion of the good and bad points of that interface. I then xerox

the critiques (first covering the name of the author of the essay),

and give each group copies of the essays that critique that group's

deliverable.

 

I find these critiques to be one of the most valuable parts of the

course. The groups benefit from receiving feedback from their fellow

students, as well as from myself. The student critiques are generally

felt to be very useful in highlighting the successful/unsuccessful

portions of the deliverable, and as such are good sources of ideas

for improving the group's project. Since each of the groups is

working on a different project, the students don't feel that they are

in competition with the other groups, and so feel free to share ideas

and suggestions. The essay assignment also allows/forces students to

closely examine the work of other groups, which gives the students a

better idea of the range of quality of student work and the different

approaches to presentation issues that exist within that course.

 

######################################################################

 

Title: Projects in Real-Time Software Engineering Courses

 

Author: Janusz Zalewski

jza@ece.engr.ucf.edu

http://www-ece.engr.ucf.edu/~jza/

 

Institution: Computer Engineering, Univ. of Central Florida

 

Summary Page:

 

The type of the project course:

- Projects proposed and supervised by faculty members in areas of

their expertise.

 

The project course is taught at the graduate level (3 credit hours)

 

The objectives of the project course:

- Offer students an opportunity to apply practical concepts and

principles of real-time software development on an industrial

scale project.

Secondary Objectives:

- better prepare students for industrial projects,

- develop ability to work in a team,

- enhance communication skills and writing skills,

 

Project course is offered in the Computer Engineering Degree with

Software Engineering Specialization

 

Project workload:

- project is a part of a general Software Engineering course

 

Rating of the impact of the project course on the market value of

Graduates (1-low to 5-very high):

5+ - very, very high

 

Recent graduates got employment at Intel, Motorola, Oracle, Microsoft,

Lockheed Martin, Siemens, GTE, NASA, etc.

 

Detailed Description:

 

http://reach.ucf.edu/~eel6897/

 

Janusz Zalewski

Computer Engineering

University of Central Florida

Orlando, FL 328167-2450

 

1. Objective

 

Offer students an opportunity to apply practical concepts and

Principles of real-time software development on an industrial scale

project. There are no commercial objectives in this project, only

academic.

 

2. Assumptions

 

2.1 Industry has its own organizational structure, which is hard to

imitate in the academic environment. So no attempt is made to

duplicate this structure in the project's framework. Only selected

aspects of the industrial scale project are included.

 

2.2 It is critical to state up-front what industrial aspects are

addressed in the project: organization, management, quality

assurance, development, maintenance, etc. This particular project

addresses Software Development only.

 

3. Focus

 

Course title: "Software Development for Real-Time Engineering

Systems", determines the Real-Time focus. Additional focus is kept

on Networking Software to make this project naturally extensible to

the next semester course on "Computer Networks Software Design".

 

4. Emphasis

 

Keeping the objective and focus in sight, the emphasis is on giving

students a chance to acquire or enhance Technical Skills (as opposed

to management skills). This emphasis determines project's heavy

orientation toward the use of software development tools.

 

It's a fact of life that in the development of real-time software for

modern applications, the role of automatic software development tools

has significantly increased and nearly replaced the use of

programming languages. This is due to the complexity of these

applications and a growing need to automatize the design process,

control the project, generate code, simulate the behavior, evaluate

performance, guarantee safety, etc.

 

5. Project Organization

 

 

5.1 Prerequisite Knowledge

 

Minimum: General Software Engineering course or sufficient industrial

practice. Previous class in concurrent or multithreaded programming

is a big plus.

 

Partially introduced in lectures during this course are:

- real-time software architectures

- UML notation, with emphasis on statecharts

- conceptual understanding of development tools in four aspects:

modeling capabilities, tool connectivity, portability of models, and

tool fitness into the development cycle.

 

Project domain knowledge has to be studied from documentation

provided by instructor. For example, for the Air Traffic Control

System, we collected an entire library of documents useful in

understanding the domain concepts and problem requirements.

 

5.2 Staffing

 

This is an elective graduate course offered once per year with

Enrollment of 40-50 students. Student population is divided into

teams with max. 4 persons per team. Individual work (1-person teams)

is also allowed on a case-by-case basis. Under no circumstances more

than 4 students can work on a single team (3 is an optimal number).

This is because teams greater than 3 members tend to distribute work

very unevenly, and some members do not do enough work and do not

learn enough. It is also important to realize that students on a

team learn from each other and with bigger teams this is less likely

to happen, due to decreased communication, schedule conflicts and

other interactivity related issues.

 

Another important issue is how to grade individually a piece of work

Done by a team. A partial solution to this problem it to request a

team to provide data on percentage of the project performed by each

team member.

 

The only supervisor is the instructor. There are no Teaching

Assistants.

 

5.3 Schedule

 

This project must lead to an implementation, so all primary

Development phases are covered: Specification, Design, Coding and

Testing. A sample schedule (for 12-15 Week Semester) looks as

follows:

 

Phase 1: Develop Software Requirements Specification (SRS)

Step 1: Preliminary SRS Documentation ready - Week 2

Step 2: Presentation in class on SRS - Week 3

Step 3: Deliverable - Final SRS - Week 4

 

Phase 2: Develop Software Design Description (SDD)

Step 1: Preliminary SDD Documentation ready - Week 6

Step 2: Presentation in class on SDD - Week 7

Step 3: Deliverable - Final SDD - Week 8

 

Phase 3: Develop Implementation (Code and Test)

Step 1: Test Plan ready - Week 9

Step 2: Module testing completed - Week 10

Step 3: Integration testing completed - Week 11

Step 4: Demonstration of the entire project - Week 12

Deliverable - User Manual (including Code and Test Results)

 

Phase 4: Maintenance Weeks 13-14

Steps vary depending on team and progress

 

5.4 Other Issues

 

Format of the documents is prescribed up-front and based on IEEE

Standards, however, adjusted to the needs of the academic project.

For instance, sample instructions for an Overview (Section 4) of the

SRS look as follows:

 

1) Identify ALL INPUTS (signals, messages, data items, etc.)

your Module needs for processing.

2) Identify ALL OUTPUTS (signals, messages, data items, etc.)

your Module produces as a result of processing.

3) Identify ALL FUNCTIONS your Module is supposed to perform,

that is, apply to INPUTS to produce OUTPUTS.

4) As far as possible, use UML's Use Case diagrams to describe

the functionality of your Modeule

5) As far as possible, use UML's Sequence Diagrams, to describe

the sequencing and timing behavior of your Module.

 

Level of individual decisions:

* Overall real-time software architecture is suggested by instructor.

* Implementation language is selected by instructor.

* Individual module architecture and detailed design are proposed by

students.

* High degree of freedom to select tools by students from the list of

10-12 available.

 

6. Conclusion

 

6.1 Skills training

 

Since there is heavy orientation on the use of tools, this course may

Look like skills training, but it is not. The use of tools is never

taught, students master them themselves and apply in the development,

replacing paper and pencil, which were the primary and only tools in

the past. After all, what is the role of programming languages,

aren't they only the tools to illustrate concepts? In modern software

development the role of programming languages is being replaced by

software tools.

 

6.2 What distinguishes this course from other approaches to teaching

a project course

 

* This project is of significant complexity and we have to take some

drastic decisions to scale it down to a size, which is manageable as

a class exercise for a 3-month semester.

 

* Most teams work on the same project, developing or maintaining

different components.

 

* Project has heavy orientation on the use of automatic development

tools.

 

* Software developed in this project is usually used in the following

course during next semester.

 

6.3 What works and what does not work?

 

In my opinion, everything works, provided you have enough time and

enough expertise to do it. With these two limitations, the most

likely problems come from the following:

 

* inadequate domain knowledge; this may become a serious problem if

one cannot approach experts or they are unwilling to respond; we are

resolving these issues by collecting sufficient documentation from

which requirements can be derived

 

* insufficient tool knowledge; this is less of a problem, because

students do not have to be encouraged to learn how to use a tool and

dig into its documentation to resolve problems; when technical

support needs to be called, then problems arise because vendors, who

provide the tools for free or for educational discount are treating us

with significantly lower priority

 

* large size of the project; this is resolved by an option of

extending the project throughout the next semester course, making it

continuous

 

* it is difficult to teach concepts or theory and apply it in practice

in the same course with a project of significant complexity.

 

6.4 Other problems in teaching a project course and solutions

 

* inappropriate supervision and coordination; instructor's task is

very difficult, because he has to manage 40-50 person team; because

of this load, I do not emphasize enough certain issues, such as

different roles of team members, do not require keeping journals

(just don't have time to read them), etc.

 

* it is always a significant issue in a project course: how to stick

to teaching principles if there is so much development (read:

production); this is especially true when one offers an opportunity

to use tools

 

* how to address quality issues in a project course; due to time

restrictions, I cannot do it completely in the same course;

fortunately, I teach another course on Software Quality Assurance,

where a particular project like this can be used as a vehicle for

quality assessment.

 

6.5 The impact of the project course on the market value of

graduates.

 

The market value of graduates, who know how to use automatic

Development tools is tremendous, because employers do not have to

make that much investments in their training.

 

But what counts even more, is not only practical knowledge of

Specific real-time software development tools. Because students grow

in the "tools culture", companies in domains unrelated to real-time

software development, such as VHDL design, are happy to hire these

students too, since it's clear that a student can easily adjust to a

new tool from a different domain.

 

Our recent graduates got employment at Intel, Motorola, Oracle,

Microsoft, Lockheed Martin, Siemens, GTE, NASA, and other smaller

Software development companies.

 

######################################################################

 

Title: Software Engineering Project Course at National University

of Singapore

 

Author: Stan Jarzabek (stan@comp.nus.edu.sg)

 

Institution: Department of Computer Science, School of Computing,

National University of Singapore (NUS)

 

Summary Page:

 

The type of your project course:

Industry involvement: no

- Project(s) formulated and conducted by a small number of faculty

members specializing in Software Engineering, with faculty members

and teaching assistants supervising student teams.

 

The project course is taught at the undergraduate level

 

The objectives of the project course:

- better prepare students for industrial projects

- develop ability to work in a team

- enhance communication skills and writing skills

- enhance project planning skills

- consolidate and apply in practice software design principles

acquired in earlier programming courses

 

Project course is offered in the:

- general Computer Science programme

 

Project workload:

- full-fledged project course with workload equivalent to two

typical one-term courses (2 X 13 weeks)

 

Rating of the impact of the project course on the market value of

Graduates (1-low to 5- very high):

Too early to rate the impact, we have offered this project course

only twice.

------------------------------------------------------------------

Detailed Description:

 

At the National University of Singapore (NUS), we experimented with

various approaches to teaching project courses. Although our students

do projects that emphasized real world experiences (we have the

co-op programme and a university project course emulating real

world situation), the industry surveys were consistently signaling

the same problems related to weak development and communication

skills in team-based, large scale software projects. We tried to

address some of the problems with a new project course focusing on

application of principles and "best practices" in large-scale

team-based development. We offer this new project course in addition

to other courses that emphasize real world experiences.

 

MOTIVATION FOR THE NEW SOFTWARE PROJECT COURSE

 

We observed that when exposed to real world pressures, our students

did not know how to take advantage of what they learned in earlier

programming and software engineering courses. Students tended to

perceive principles as obstacles rater than tools that can help in

project work. Assignments in programming courses involve small

programs, while one can only appreciate the value of principles when

it comes to large programs, developed by teams. Therefore, students

have little opportunity to observe why we really need modeling,

software architecture, interface definitions, separation of concerns,

information hiding or a systematic approach to testing. For example,

if 1-2 students can develop a program working closely together in a

couple of days and the assignment requires them to define an

architecture and interfaces, they will do so just to satisfy

assignment requirements, not because there is a real need for those

artifacts in the context of practical goals. The value of

architecture and interfaces only shows in programming-in-the-large,

when we need to understand different program parts separately, split

the job into tasks that are completed in a fairly independent way and

develop a product incrementally rather than in one shot.

 

THE NEW PROJECT COURSE

 

We postulated that there was too a big gap between programming and

software engineering courses, in which students learn about "best

practices" and principles, and real world projects. We decided to

fill this gap with yet another project course that would focus

on application of design principles in a large-scale, team-based

project. We adopted a rather formal approach to teaching this new

project course, with little emphasis on real world experiences such

as negotiating requirements with customers. The new course does not

replace but complements other project courses we have been offering

to our undergraduate students.

 

Improving communication skills is the major concern and focal point

in the project course. Both communication with a customer and

communication among project team members are important but in this

course we focus on the latter. Ability to express solutions at the

concept level, to properly document design, code, test plans and

other program artifacts, to describe interfaces and to use assertions

are all related to communication skills. So is the ability to prepare

and conduct team meetings in an effective way. Communication skills

integrate essential human and technical aspects of software

development. As students do not have enough opportunity to develop

communication skills in assignment- based courses, it is the major

challenge for the project course to address this issue. We define

programming problem and the development process in such a way that

students can experiment with a wide range of techniques related to

mastering communication skills.

 

We clearly define the project goals in terms of software product

qualities such as flexibility or reliability, as well as

functionality. Using problem-based learning approach, we

show the students benefits of applying principles

and "best practices" to achieve project goals. By following

and extending examples, students start appreciating the value

of principles and get working knowledge of how to apply them

in-the-large. We formulate and conduct the course project in

such a way that it is impossible for students to achieve

project goals unless they follow the path of "best practices"

we are showing to them. The incremental development process

for the project reflects development practices used in advanced

industries, emphasizes the role of software architecture and

encourages systematic, well-planed development.

 

CONDUCT OF THE PROJECT COURSE

 

Students do the project in teams of 6, under close supervision of

instructors and teaching assistants who share a common vision of the

project course objectives and are prepared to guide students through

the project to meet the objectives.

 

The project course starts with 8-10 lectures during which the chief

instructor motivates the students, explains the programming problem

and the development process. Students spend two weeks on problem

analysis. At the same time, they develop a throw-away prototype. In

the next two weeks, students develop the first sketch of a software

architecture. This includes subsystem level decomposition

and description of subsystem interfaces. At this point, each team

splits into two groups of 3 students. Each group works on a fairly

independent subsystem. The subsystems communicate via a non-trivial

interface and both groups communicate and refine interface

specifications throughout the project. Students develop the project

in iterations, incrementally. Each new iteration extends the program

implemented in the previous iteration. The iterative development

helps students tackle project difficulties one by one, applying

principles of separation of concerns, abstraction and refinement

 

Program reliability is emphasized throughout the project. An

Important aspect of reliability is comprehensive testing. In the

project, we expect program reliability close to industry standards.

Students are advised to allocate enough time for test planning and

testing, to make unit testing an integral part of development and

to do integration testing and system testing at the end of each of

the development iterations. Students use a public domain testing

tools.

 

We give students a set of course handouts that includes problem

description, compendium of recommended software engineering practices

for the project, sample solutions illustrating how we expect them

to approach design problems and technical tips.

 

A common problem is to find enough faculty members and teaching

assistants qualified to do the job. It takes a long time before

teaching assistants can provide useful advice to student teams.

These problems escalate when the project course is offered to large

population of students. At NUS, project course is compulsory for all

Computer Science students, around 500 students per year, and is

offered in both terms. It is essential that all the supervisors share

a common vision of course objectives. To address this problem, we

prepared a comprehensive project framework that shortens the learning

time before the new instructors and teaching assistants can

effectively advice student teams. Before the project course starts,

the supervisors study the course materials to get familiar with the

programming problem, development process and software and methods to

be used in the project.

 

RESULTS SO FAR

 

We see a big difference in the way students deal with team-based

software development at the end of the project as compared to their

approach at beginning of the course. Students appreciate the role of

software architecture, learn how to communicate in terms of

interfaces, how to split the project work and document the work

products in a clear way, understandable to their team mates. Most of

the teams become very much involved in the project and motivated to

work hard in order to deliver a quality product. Though in this

course we make little effort to emulate real world situations, we

believe students learn some essential skills that will help them to

deal with real world project challenges in a systematic rather than

chaotic way. We also believe that this type of a project course

should be a part of the software engineering curriculum to ensure

that students get a working knowledge of design principles taught in

other courses.

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Upcoming Topics

 

######################################################################

 

Software Engineering as a Profession in the United Kingdom

 

Guest Editors for this Upcoming Topic:

 

Barrie Thompson and Helen Edwards

University of Sunderland

barrie.thompson@sunderland.ac.uk, helen.edwards@sunderland.ac.uk

 

For more information on this topic, please contact the guest editors.

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Articles

 

######################################################################

 

Ideas and Issues in Software Engineering Education

 

Tom Hilburn

 

The May 2001 issue of Computer (vol 34, no 5, pp 28-35) includes an

article by Betrand Meyer titled "Software Engineering in the Academy".

I recommend it to those that are trying to develop and enhance quality

software engineering programs. As an antidote to some of the

shortcomings in current software development Meyer proposes five

elements for software engineering curricula:

1. principles: lasting concepts that underlie software engineering

(e.g. abstraction, information hiding, recursion, reuse, exceptional

handling , etc.)

2. practices: problem-solving techniques that good professionals

apply consciously and regularly (e.g., configuration management,

metrics, documentation, high-level system analysis, etc.)

3. applications: areas of expertise in which the principles and

practices find their best expression.

4. tools: state of the art products that facilitate application of

software engineering principles and practices.

5. mathematics: the formal basis that makes it possible to

understand everything else

 

Although there may be some disagreement with the organization and

details of these curriculum elements they provide a nice

representation against which one can compare and contrast the goals

and design of an existing or proposed software engineering program.

 

Meyer makes several references to David Parnas' paper "Software

Engineering Programmes are not Computer Science Programmes" (Annals of

Software Engineering, vol. 6, April 1999) Parnas provides a different

perspective on software engineering curricula by arguing that computer

science provides a scientific and conceptual base for software

engineering curricula, but the structure, objectives and activities of

such curricula must be similar to the "traditional" engineering

programs. If you have not had a chance to look at this, it is

important, though controversial, contribution to the debate about

software engineering education.

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Book Reviews

 

######################################################################

 

Title: Software Fundamentals: Collected Papers by David L. Parnas

Edited by: Daniel M. Hoffman and David M. Weiss

Publisher: Addison-Wesley (http://www.awl.com)

ISBN: 0-201-70369-6

Hardcover, 664 pages

 

Reviewed by Don Bagert

 

Surprisingly enough, for all of his pioneering efforts in computer

science and software engineering, Dave Parnas has never written a

book. Now he has - in a manner of speaking. This book is a

compilation of 33 articles by Parnas on a wide range of subjects in

software engineering. There are introductions to most of the articles

by many of his well-known software engineering colleagues, including

Barry Boehm, Victor Basili and Leonard Tripp.

 

The articles are grouped into four parts: description and

specification, software design, concurrency and scheduling, and

commentary. Parnas provides a new introduction to each of these

four sections.

 

The "Commentary" section is where Parnas discusses education and

professional issues (among other things), and so is likely to be of

the most interest to FASE readers. Among these articles are "The

Professional Responsibilities of Software Engineers", "Teaching

Programming as Engineering", and "Software Engineering: An

Unconsummated Marriage" (as reported in "David Parnas has CACM

Column on Software Engineering" in September 1997 FASE).

 

At the end of the book is a bibliography of Parnas' 210

publications, as well as a detailed index (which is often not found

in such paper compilations).

 

Parnas is one of the greatest computer scientists and software

engineers of our time. He is also a gifted author and speaker,

and never afraid to be critical in his commentary when trying to

make a point. Some readers will enjoy these commentaries, while

others will like the more straightforward research papers on various

aspects of software engineering. In other words, there is something

here for everyone.

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

News Items

 

######################################################################

 

ICSE Holds Panels on Software Engineering Education, SWEBOK

 

The 23rd International Conference on Software Engineering (ICSE 2001),

held in Toronto, Ontario, Canada on 12-19 May, contained several

items of interest concerning software engineering education and

professional issues. The first was a panel on software engineering

education held as part of the David L. Parnas Symposium, honoring

the software engineering pioneer on the occasion of both his 60th

birthday and the publication of his first book (see separate article

for a review of it). Entitled "Accredited Software Engineering

Programs: Form and Content", it included three professors (Parnas

of McMaster, Tim Lethbridge of the University of Ottawa and Mike Lutz

of Rochester Institute of Technology) whose respective universities

have undergraduate software engineering programs which either are or

soon will be seeking accreditation, and Jim Waldo of Sun Microsystems.

 

During the conference itself, there were six papers on software

engineering education, plus a panel on SWEBOK [1] moderated by

Peter Freeman, Dean of the College of Computing at Georgia Tech

University (and which included Don Bagert, FASE Professional Issues

Editor). An issue frequently brought up during the question and

answer period of the session was the fact that many people still

see the SWEBOK project as linked to the licensing and certification of

software engineers, which was a contributing factor to ACM's

Withdrawal from the Software Engineering Coordinating Committee last

year (see "ACM Withdraws from SWEcc" in the July 2000 FASE).

 

References

 

[1] Bagert, Donald J.; Dupuis, Robert; Freeman, Peter; Saiedian,

Hossein; Shaw, Mary and Thompson, J. Barrie. Software engineering

body of knowledge (SWEBOK). Proceedings of the 23rd International

Conference on Software Engineering, Toronto, Canada, 12-19 May

2001, pp. 693-696.

 

######################################################################

 

By: Don Bagert (Professional Issues Editor)

 

New SE Professional Society Holds Workshop

 

The new Software Engineering Society (SES) held its first major event,

the Workshop on Global Transdisciplinary Education Research and

Training, on 11-13 June 2001 in Pasadena, California, USA.

 

The SES has a vision "of raising Software Engineering to new heights

it deserves as the first true transdiscipline - the discipline in

between disciplines." Its mission is "Serving Software Engineers

throughout the world."

 

The Software Engineering Society was founded by computing pioneers

C.V. Ramamoorthy and Raymond T. Yeh.

 

For more on the Software Engineering Society, see

http://www.ssenet.org

 

######################################################################

 

From: Canadian Council of Professional Engineers via several sources

 

Canadian Council of Professional Engineers and Microsoft Corp. Agree

on use of "Engineer" title

 

Ottawa, Ontario, May 11, 2001 - After discussions with Canada's

engineering profession, Microsoft Corp. will advise Canadian holders

of its MCSE certification not to call themselves engineers or use the

full title Microsoft Certified System Engineers.

 

Microsoft's decision should prevent Canadian holders of the MCSE

certification from inadvertently breaking provincial and territorial

laws, which protect the public by restricting the use of the titles

"engineer" and "engineering" and the practice of engineering in

Canada to licensed professional engineers. It should also ensure that

the engineering profession's licensing bodies will not be required to

take enforcement action against MCSE holders who mistakenly use the

title engineer or otherwise hold themselves out as having been

qualified to practice engineering.

 

"We are very pleased by Microsoft's decision," said Marie Lemay,

P.Eng., CEO of the Canadian Council of Professional Engineers (CCPE).

"Microsoft has demonstrated corporate leadership by acting in the best

interest of the MCSE community. Holders of the MCSE certification are

not licensed or regulated by the engineering profession. If they

mistakenly use the titles "engineer" and "engineering" the provincial

or territorial engineering associations/order would have to take

enforcement action against them. Its decision is good for the

information technology industry, good for MCSE holders, and good for

the engineering profession."

 

The engineering profession, represented by CCPE and several provincial

engineering regulatory associations, met with Microsoft in Seattle

late last year to explain the legal issues surrounding the use of the

title "engineer" in Canada, and to ask the corporation to stop

referring to holders of the MCSE credential as engineers. Canadian

MCSEs have received certification as Microsoft Certified Systems

Engineers, which could lead them to mistakenly misuse the title

"engineer."

 

"We are very pleased to have reached an agreement with the

engineering profession and to support it," said Anne Marie McSweeney,

the acting Director of Microsoft Certification and Skills Assessment.

"It opens the door for closer cooperation among all organizations in

the information technology industry and the engineering profession in

Canada. As the Microsoft credentials continue to evolve, it is our

goal to ensure they maintain the highest level of relevance to the

industry and represent leaders in cutting-edge technology."

 

Microsoft is currently researching alternatives for the MCSE

credential worldwide, which could result in a new name for the

credential later this year.

 

CCPE is the national organization of the provincial and territorial

associations/ordre that govern the practice of engineering in Canada

and license the country's 157,000 professional engineers. Established

in 1936, CCPE serves the associations/ordre, which are its constituent

and sole members, through the delivery of national programs which

ensure the highest standards of engineering education, professional

qualifications and ethical conduct.

 

For More Information Contact:

Terence Davis, Manager, Communications, CCPE

613 232-2474, ext. 238

 

######################################################################

 

From: UT-Dallas via Scott Andresen of IEEE-CS

 

UT-Dallas to Launch Software Engineering Degree Program

 

New Bachelor's Degree to be One of Few Such Offerings in the Country

 

RICHARDSON, Texas (June 7, 2001) - The University of Texas at Dallas

(UTD), which several years ago became the first university in the

United States to offer a bachelor's degree in telecommunications

engineering, is preparing to join the ranks of a select group of

universities that grant a B.S. degree in software engineering.

 

Students in U.T. Dallas' Erik Jonsson School of Engineering and

Computer Science will be able to enroll in classes under the new

degree program beginning this fall.

 

UTD, with one of the top-ranked engineering and computer science

programs in the nation, already offers a master's degree in computer

science with a major in software engineering. In addition, the

university is reviewing a proposal to begin offering a Ph.D. degree

in the same discipline.

 

"This new degree program will both broaden the scope of UTD's

engineering and computer science offerings and help meet the

increasing need from industry for software engineering training,"

said Dr. Simeon C. Ntafos, professor of computer science, who this

fall will become director of a new Software Engineering and Systems

Division of the Computer Science Department. "UTD will become one

of only a handful of universities in the U.S. to offer a degree in

this rapidly-growing field."

 

According to Ntafos, the software engineering degree should

have substantial appeal to the North Texas region's "Telecom

Corridor," home to as many as 900 high-technology companies. Many

of those firms, located in close proximity to UTD, have close ties

to the university through involvement in research and hiring its

graduates.

 

The new degree program will be similar to that of an

undergraduate computer science degree, but will require that students

enroll in five courses specific to software engineering

- basic software engineering, requirements engineering, software

architecture, testing and quality assurance and a "capstone" project.

 

The project class, to be taken during a student's senior year,

will involve student teams taking a substantial software system

through all stages of development.

 

UTD will seek ABET accreditation for the software engineering

degree, Ntafos said.

 

For additional information about UTD, please visit its web site at

http://www.utdallas.edu.

 

######################################################################

 

By: Don Bagert (Professional Issues Editor)

 

Parnas Writes Pro-Licensing Article for Canadian Engineering Magazine

 

Professor David L. Parnas, one of the pioneers of software engineering

and a licensed professional engineer in the province of Ontario,

Canada, contributed the Viewpoint article "Why Software Developers

Should be Licensed" for May/June 2001 issue (Volume 22, Number 3) of

Engineering Dimensions magazine, on pages 36-39. (Engineering

Dimensions is published by Professional Engineers Ontario.)

 

Parnas writes: "Over the last few decades, software has been

replacing mechanical, electrical and electronic components in

traditional engineering products. It has also become a critical

component in medical devices, chemical plants, buildings, and

aircraft. Software is regularly used to design critical products,

the effectiveness and safety of which can depend on the correctness

of that software...

 

"...Licensing and certification are needed to identify those who have

the appropriate educational background. Licensing is essential for

professionals who deal directly with the public or who are responsible

for critical products. Certification will be useful to those who will

be a part of a team and report to more senior professionals who are

able to evaluate their work."

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Calls for Participation

 

######################################################################

 

From: Heidi Ellis <heidic@rh.edu>

 

TOOLS USA 2001

Workshop on Education and Training (WET)

 

Sunday, July 29th, 2001

 

FIRST ANNOUNCEMENT AND CALL FOR PARTICIPATION

 

This year, the Workshop on Education and Training will focus

on the relationship between industry and academia, concentrating

on two loosely-related themes:

 

-- in educating and training the next generation of software

engineers, what should academia do and what should industry do?

 

-- how can industry and academia further exploit the Internet for

education and training?

 

You are cordially invited to submit a one to two page position paper

addressing either or both of these themes. Your paper should cover:

your interest in the topics, any relevant experience you can bring

to the workshop, a brief autobiography, and contact information.

 

Position papers should be submitted by June 15th, 2001 (flexible)

by e-mail in plain text format to the workshop organiser,

Heidi Ellis (heidic@rh.edu).

 

The Workshop will be informal in style, as in previous years.

Emphasis will be placed on exchanging hard-won experience and

forming useful contacts for the future.

 

We hope to be able to welcome you to the Workshop in beautiful

Santa Barbara!

 

Further details:

 

Heidi Ellis,

Associate Professor

Dept. of Computer and Information Sciences

Rensselaer at Hartford

275 Windsor St.

Hartford, CT 06120

 

Richard Mitchell,

InferData Corporation

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Position Openings

 

######################################################################

 

From: Fran Devore <fdevore@titan.iwu.edu>

 

Illinois Wesleyan University

Bloomington, Illinois 61701

Department of Mathematics and Computer Science

 

The Department of Mathematics and Computer Science at Illinois

Wesleyan University seeks an individual to teach first year courses in

computer science and/or mathematics in either a full-time or part-time

position. The appointment will be for the fall term and will begin in

August 2001. Reappointment for the spring term 2002 should be

possible. Candidates should have a graduate degree in either Computer

Science, Mathematics, or a related area.

 

Illinois Wesleyan University is a highly selective undergraduate

university of approximately 2,000 students located in Bloomington,

Illinois, a community of about 120,000. The Department of Mathematics

and Computer Science is located in the Center for Natural Science

Learning and Research, a $25,000,000 facility opened in 1995.

 

Candidates for the position should submit a letter of application, a

resume, and have three letters of recommendation sent separately to:

Judy Huff, Natural Science, Illinois Wesleyan University, P.O. Box

2900, Bloomington, IL 61702-2900 [jhuff@titan.iwu.edu, (309) 556-3060]

 

Applications will receive immediate attention. The University invites

retired faculty and ABD's to apply. Women and minorities are

encouraged to apply. Illinois Wesleyan is an Equal Opportunity

Employer. For further information see our jobs web page at:

http://www.iwu.edu/~iwujobs

 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

Contact and General Information about FASE

 

FASE is published on the 15th of each month by the FASE staff.

 

Article and Faculty Ad Submission Guidelines

 

Send newsletter articles to one of the editors, preferably by

category: Articles pertinent to academic education to Tom Hilburn

<hilburn@db.erau.edu>; corporate and government training to David

Carter <dacarter@bayou.com>; professional issues, faculty ads, and all

other categories, to Don Bagert <Don.Bagert@ttu.edu>. If the article

is for a FASE topic where there is a guest editor, the submission

should instead be to that person, according to the schedule provided.

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).

_____

 

Subscribe/Unsubscribe Information (as of February 15, 2000)

 

Everyone that is receiving this by email is on the FASE mailing list.

If you wish to leave this list, send a message to

 

<lyris@lyris.acs.ttu.edu>

 

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

 

<lyris@lyris.acs.ttu.edu>

 

and, in the text of your message (not the subject line), write:

 

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

 

<lyris@lyris.acs.ttu.edu>

 

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, training and professional issues; 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.

 

As always, there is no cost for subscribing to either FASE or

FASE-TALK!

 

(Subscriptions can also be maintained through the Web via

http://lyris.acs.ttu.edu. From there, click on "TTU Faculty Mailing

Lists", and then either "fase" or "fase-talk", depending on which list

you desire.)

_____

 

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, or

<http://www.cs.ttu.edu/fase/reverse.htm> in reverse order.

_____

 

The FASE Staff:

 

Tom Hilburn -- Academic Editor

Embry-Riddle Aeronautical University

Department of Computing and Mathematics

Daytona Beach FL 32114 USA

Phone: 904-226-6889

Fax: 904-226-6678

Email: hilburn@db.erau.edu

URL: http://faculty.erau.edu/hilburn/

 

David Carter -- Corporate/Government Editor

6212 Mil Mar Blvd

Alexandria LA 71302 USA

Phone: 318-767-2339

Email: dacarter@bayou.com

 

Don Bagert, P.E. -- Professional Issues/Misc Editor and Web/Listmaster

Department 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

 

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