This excellent paper “focuses on things that a software developer must be able to do when developing and maintaining a product” and proposes a body of fundamental capabilities that were needed when the software engineering profession was first identified (in the 1960s), that are needed now, and that will be needed in the far future. The authors explain: “The paper deliberately avoids naming any particular techniques, technologies and ‘methodologies.’” Such an emphasis on fundamentals, as opposed to buzzword-compliant artifacts, has often been a desideratum both in software development and in its teaching. A few exceptions have existed since the 1960s (for example,  and other books and papers by software pioneers), but the state of the practice still leaves much to be desired. I think it is perfectly illustrated by the term “software guru” :
If the company software guru is an experienced C (or X or Y or Z) hacker then it is likely that he will recommend what he already knows for any job that comes along; this is the best way of preserving his guru status. Much recruitment of software engineers suffers from this kind of confusion. […] As an aeronautical engineer I am amused by the idea of applying for a job at Boeing or Airbus quoting my “skills” as: screwdriver, metric open-ended spanners and medium-sized hammers!
The authors quote Brian Randell, one of the authors of , who describes software engineering as the multi-person development of multi-version programs. This distinguishes professional from amateur programming; for an excellent discussion of these and related issues, see another classical text . Most ideas and “war stories” described there are still valid for all stages of software development, including modeling and design.
The paper enumerates 12 fundamental capabilities that will remain important through a graduate’s career. The first and most important of them is still a desideratum: “Communicate precisely between developers and stakeholders.” (It is also the first one in “What makes a good program” in .) The fact that Bertrand Meyer relatively recently had to stress that “[t]here is no justification for renouncing the basic engineering technique of specifying what you are going to do, in writing, and at appropriate level of detail, before you do it” , clearly demonstrates that very serious problems still exist in software development.
The authors properly emphasize that a statement of requirements may not be correct but must be “precise, readable, and demonstrably formally complete,” and that stakeholders have to “review, correct and (eventually) accept” it; obviously, imprecise or unreadable (by stakeholders) requirements cannot be corrected. The authors do not mention, however, the need for and stability of business domain specifications (as opposed to volatile requirements): most domains have remained relatively stable for decades if not centuries. Regretfully, “[i]n contrast with other types of engineers, ‘software engineers [generally] do not know how to model the domain in which their software operates’ . If only those who are mesmerized by their employees’ C++ skills would finally understand this!” .
The second fundamental capability instructs: “communicate precisely among developers.” Here, the authors very explicitly state that “in digital technology very small misunderstandings can lead to major failures.” This certainly also applies to the need to articulate tacit assumptions of different stakeholders and different developers in the process of specifying the business domain and requirements.
Proper documentation is also at the center of several other capabilities, such as designing human-computer interfaces (a multidisciplinary subject), designing and maintaining multi-version software, designing software for reuse (this includes reusable specifications such as domain models), ensuring that software products meet quality standards, creating and using models, being disciplined in development and maintenance, and so on.
The authors stress the need to use non-toy projects, including multi-person projects, as “major constituents” of a software systems engineering program. Graduates could present a “portfolio” of completed projects to prospective employers. As an important addition, I think that examples of failed projects, with clear explanations of why they failed, must be presented to students. For an example of failures due to the absence of an explicitly articulated abstract business model, and of a successful firm that solved this problem, see .
The authors do not present a selection of texts (books and papers) for students; however, in my opinion and experience, texts by software pioneers successfully solve the problem of bestseller-oriented courses that quickly become outdated.
Summing up, I highly recommend this very important paper for both academic and industry readers. Note that “work on this paper began when the authors served on a committee advising Israel’s Council of Higher Education that was chaired by David Parnas.” Readers may also want to ponder the strength of the academic enterprise, as described by E. W. Dijkstra .