Randell described software engineering as “multiperson development of multiversion programs.” Brooks said that, in addition to writing code, software engineering required both combining separately written programs and “productizing” them—that is, making them suitable for use by people who had not written them. These topics usually received little or no attention in traditional programming courses.

We were able to identify a set of capabilities required to do the things that Randell and Brooks had identified as differentiating software development from basic programming. The accompanying table lists those capabilities but readers really should read the paper to see what is meant. They will find detailed, concrete justifications, definitions, and guidelines.

 

You used “software systems engineering” to denote the class of programmes you were discussing. That class included both specialized programmes and general software engineering programmes. You listed 12 capabilities that should be imparted to software systems engineers. They are all engineering capabilities. How should this be used?

tional engineering education taught methods of designing and constructing reliable products, they proposed that that software development should be regarded and taught as an engineering discipline rather than as a branch of science.

How did universities respond to the
conferences?

After the conferences, software engineering was treated as the area within computer science that studied ways to produce safe and reliable products. Some included project management within the field.

The initial response was to add a
single one-semester course entitled
“Software Engineering” to CS curricu-
lums. It was not clear what should be
taught in such a course. When I was
assigned to teach that course, I asked,
“What should it cover?” The only an-
swer was “Dave, you are an engineer—
you figure it out.”
Later, as software became more im-
portant, CS departments defined soft-
ware engineering “tracks” that included
additional required courses—such as
compilers, database systems, and soft-
ware test methods. Important aspects
of engineering such as interface design
and fault tolerance were rarely included.

On a number of occasions, you wrote
sharp critiques of many of these pro-
grammes.a What was the basis of your
criticisms? Did they produce results?

My first critique 6 complained about many aspects of the “tracks.” I pointed out they were teaching topics that interested the teachers rather than what the students would need to know as professional software developers.

My second major commentary7 was written after my university ( McMaster) had formed a new department and was offering a program designed to be taught in the engineering faculty rather than the science faculty. It had no courses in common with the previously existing CS program. Students took the same first-year courses as all other engineering students; only at the end of that common first year could they select software engineering as their programme.

 

a “Programme” is used in the context of this interview to refer to a course of study at a university and to differentiate from a software program.

The point of both of these papers was that software engineering education should be considered professional education (like architecture, medicine, law or engineering) rather than based on a “liberal arts” model like physics or mathematics.

Our programme was designed to be accredited by the Canadian Engineering Education Board. In the year we graduated our first students, two other Canadian Universities were also accredited and graduated students.

Both papers generated a lot of discussion. The programme described in the 1998 paper7 was well received by students and employers. Unlike graduates of CS programmes, our SE graduates could be licensed as professional engineers after passing the usual law and ethics exams.

 

In 2017, you chaired a committee that
wrote a report about software devel-
opment programmes. 1 The resulting
paper takes a capabilities-based ap-
proach to specifying the goals of pro-
fessional programs in software devel-
opment. How does this approach differ
from the more common approaches?
Previous efforts to prescribe the con-
tent of CS and SE programs were based
on the concept of a “Body of Knowl-
edge.” They specified what the students
should know when they graduated.

Noting that these were professional programs, we chose to specify what the graduates should be able to do upon graduation. Our goal was to allow individual institutions to choose the knowledge and methods that would be taught provided that they gave the graduates the required capabilities. Those who read the 2017 paper will see that the approach is quite different from earlier approaches to curriculum specification. It emphasizes software development capabilities, not the name and content of the courses.

 

The 2017 paper stresses the difference between CS programmes and professional software development programmes, basing your approach on very old observations by Brian Randell (an author of the reports on the 1968 and 1969 conferences) and Fred Brooks, author of the very popular book The Mythical Man Month. What did they say that attracted you?

List of capabilities.

Communicate precisely between developers and stakeholders Communicate precisely among developers Design human-computer interfaces Design and maintain multiversion software

˲ Identify and separate changeable concerns

˲ Document to ease revision

˲ Use parameterization

˲ Design software that can be moved to many platforms

˲ Design software that is easily extended or contracted

˲ Design and maintain products that
will be offered in many versions
Ensure software products meet quality
standards
Develop secure software
Create and use models
in system development
Specify, predict, analyze, and
evaluate performance
Be disciplined in development and
maintenance
Use metrics in system development
Manage complex projects