This is a difficult book to review. First, the title implies that it covers “the essence of software engineering,” which I consider an exaggeration. The content is definitely related to the discipline, but in a different sense. It has more relevance to software development and project management, through its software engineering method and theory (SEMAT) approach, termed the SEMAT kernel, even though it would be more appropriate to call it a framework, as the authors do occasionally.
Second, the authors introduce some terms that are not commonly used in software engineering, such as the noun “alpha” (aspiration-level progress and health attribute), the adjective “actionable” (probably meaning executable), and the phrase “software endeavor” (meaning a project or its iteration). They also give new meanings to some typical terms, such as kernel, which could confuse readers.
Finally, the book cites endorsements from some prominent figures in software engineering, including Bertrand Meyer, who also authored one of the three forewords, Dines Bjørner, and Barry Boehm.
The book is divided into six parts. Part 1 introduces the SEMAT framework, Part 2 instructs readers on how to run an iteration of a project supported by SEMAT, Part 3 provides more details on running projects, Part 4 outlines the scaling process, and Parts 5 and 6 simply advertise SEMAT by discussing how it changes the way one works with development methods and outlining what is new in this approach.
The book addresses some vital software development and project management issues, in particular the use of development methods as a part of the software development methodology. It starts with the assumption (on page xxviii) that software engineers “need an effective thinking framework” to deal with software projects, and outlines its essential objective to “present such a ... framework in the form of an actionable kernel.” The key concept is method, meaning “the set of practices and tools” that make up this way of doing software development (page 47).
The view of the software development methodology presented here roughly fits into a concept that I believe was first formulated by Jochen Ludewig . This includes not only methods, but also techniques to implement the methods and tools to automate the process. This becomes clear in a diagram on page 232, which depicts the SEMAT hierarchy as being composed of four layers, with methods on top and practices (techniques) in a lower layer, which in turn use kernel elements defined in terms of a language and located in the bottom layer.
The general perspective of the book is quite commendable, since it addresses profound problems in the discipline. When it comes to details, however, there are a number of flaws, which make the entire concept of SEMAT much less sound. Mainly, alphas, the essential entity of SEMAT, really have a double meaning: an attribute and an element of a method. With both of these meanings, there are significant problems.
Alphas include concepts such as opportunity, stakeholder, requirements, software system, work, team, and way of working. If these are attributes, then they cannot have states, as assumed in the book. An attribute is a property of an entity, which can be quantified on a certain scale but not as a state. If alphas are truly meant to have states, then there is another significant problem, because their states, as outlined in the book, do not have any transitions. This is an essential characteristic of a state-based system, to allow state-to-state transitions, which are precisely defined. This is not the case in this book.
Furthermore, one of the alphas, requirements, is placed in the alpha basket, but as I understand this term, it is not possible to make requirements into either attributes or states. Requirements usually have attributes themselves, and as such are just artifacts, not activities, and as such they cannot be subject to state changes. In Figure 3.3, the authors fail to capture the essential characteristic of a state: transitions between states based on inputs.
The book makes some unsubstantiated claims that “it will help the industry as a whole by improving interoperability between teams, suppliers, and development organizations” (page xxxviii), and I feel like it is highly overrated by reviewers. Conducting the SEMAT project may have been a thrilling experience, but the book itself does not adequately convey the findings.
However, the major issue I have with this book is that it misses one important point: the essence of any engineering discipline is design, which can hardly be questioned. Software engineering is no exception. Design is crucial in developing high-quality products.
On a positive side, if we view the book as a collection of essays, the content can definitely help readers systematize their knowledge of software engineering and strengthen their understanding of the discipline.
More reviews about this item: Amazon, GoodReads