Software engineering – a modern approach by Marco Tulio Valente is a freely available textbook published in 2024.
I first learnt about this text after carrying out some internet searches, but then later discovered that colleagues had discovered it too. I soon realised that there were a range of different opinions about it. With these differences of opinions in mind, I decided to have a good look at it to form my own opinion.
I approached it with two questions in mind: could it potentially complement the existing TM354 Software Engineering module? Also, could it be a useful resource for either module teams or students, as we work on a new version of the module? In some respects, this review follows on from an earlier blog post about the SWEBOK v4.
I begin by having a look through each of the chapters. I then reflect on what its shortcomings are. I then wrap everything up with a set of closing reflections and share a personal conclusion.
The chapters
The text begins with a bit of history, highlighting the significance of the 1965 NATO conference. Before sharing a high level summary of what is contained within the text, it shares a high level objective, which is to ‘give an overview of the knowledge accumulated over the years in software engineering and, consequently, to shed light what is studied in this field’.
Chapter 2 takes us to the subject of software engineering processes, and immediately into the world of what is meant by agile. Before we got here, we were usefully reminded that there are different types of software product and this, may well, necessitate the adoption of different approaches. A discussion about agile manifesto leads to a discussion of eXtreme Programming, Scrum and Kanban.
Next up is a treatment of requirements. Functional and non-functional requirements get a mention, as do user stories and different forms of use case. It is interesting to see the inclusion of A/B testing within the requirements chapter, but as end users of sites like Amazon, we have been unwittingly subjected to these types of tests.
The chapter about models steps into a topic that is heavily featured in TM354, but will find its way into TM253 in one way or another. After a slight digression into formal methods we are introduced to the Unified Modelling Language (UML). Curiously, UML activity diagrams (which is often about requirements) appears after sequence diagrams. Contrasting with TM354, there is nothing about state diagrams.
The chapter about design principles offers a useful compendium of ideas and concepts. Some key ideas highlighted include conceptual integrity, information hiding, cohesion, and so on. Whilst these design principles are useful, there is nothing about what design means, or how to do design. One section that I did like is the summary of the Law of Demeter, which isn’t done as well as it could be within TM354 (which is a further example about how the textbook addresses similar ideas). Also, like TM354, towards the end of the chapter, we are introduced to the idea of software complexity metrics.
Following the principles we have a detailed discussion about patterns. It presents a more detailed catalogue than what is given in TM354. Patterns takes us to the notion of architecture. This is the opposite way round to how TM354 introduces it. Ultimately, the order may well come down to pedagogic preference. In terms of software, I appreciated the introduction of the operating system design debate, which leads onto a discussion about monoliths and microservices, which is a topic that has recently found its way into the latest update of TM354.
Testing is introduced in terms of levels and scope, which are then expanded upon, beginning with unit testing. Related topics that are covered include test coverage, mocks (which is not covered in TM354), test-driven development, partitioning and boundary value analysis (which are covered in TM354). The next chapter on Refactoring is quite a practical. It shares some useful examples, and drawing on the terminology from the original Fowler text, offering a useful distilled summary.
The final two chapters, DevOps and GitHub can, to some degree, be read together. Both are important. The DevOps chapter begins with a nice summary. This leads to an introduction of the principles of the version control system (which is also addressed within TM113). Related terms, such as continuous integration and continuous delivery are introduced and explained (whilst also distinguishing between delivery and deployment). The chapter on Git introduces the key Git commands, and explains key concepts, such as merging, forking and branching.
The good points
What I like about the text is that it follows the SWEBOK relatively closely. If you know the SWEBOK, you will be able to recognise headings reflected in this book. It doesn’t just repeat a summarised version; it does add value. In addition to offering a useful bibliography, it also offers sets of questions, which are presented as exercises. The frequently asked questions sections in the chapters are helpful; they consolidate questions that students might ask during a class.
Another useful aspect to the text is that it provides numerous links to original sources or articles.
What is missing?
A few things are missing. As suggested earlier, there is a chapter on design principles, but little about the practice of design. Agile teams are mentioned, but there is also very little on how they should be formed or facilitated. This said, there are references to other resources that are helpful.
Turning to more technical elements, there isn’t much about software engineering economics, but there are references to practical techniques such as planning poker (which gets a very brief mention in TM354). I also feel that, given the importance of software security, the whole subject is underemphasised. Whilst the testing materials offers a useful high level summary, it lacks a reference to materials about Pen Testing.
From my perspective, there is no materials on the increasingly important subject of environmental computing. There should be something about energy and energy consumption, and how this might relate to software architecture. Another area that, in my opinion, ought to be covered in more depths is the subject of diversity and its important within teams.
Bearing in mind these points, a related area that is missing is the lack of consideration of the sociotechnical. It doesn’t, for example, consider the ways in which computing or information technology can be understood or situated within a human activity system. It could also be argued that the SWEBOK doesn’t do a great job of this either.
One thing I am grumpy about might be to do with the type of the text I’m using, which is the ePUB version. There isn’t an index, a glossary or a consolidated set of references, and an index about where those references are used. A further question to ask is: could I tolerate this? Possibly.
Reflections
No text is ever going to perfect and tick every single requirement box (even if we ever knew what those requirements were). Despite its gaps and shortcomings, I quite like this book. I especially like how readable it is. What it offers is a useful high level summary of many of the topics that are highlighted within the SWEBOK. I felt the section about DevOps was particularly helpful.
What I haven’t done is had a look through the resources that clearly accompany this book. There appears to be a lot: podcasts, slides, and code that can be found on GitHub. I also haven’t directly compared this text to others. Last year, I did have a quick look at a new book by Sethi, but I felt it wasn’t as clearly written as it could have been. Ian Sommerville’s text on Software Engineering remains highly regarded, but Sommerville has retired from teaching. In a field that appears to be changing quite rapidly, applicability is important.
I do feel it accidentally complements the current TM354 Software Engineering module surprisingly well. Will it complement the forthcoming TM113 and TM253 modules? I’m not sure; they are going to be quite different modules, but cover themes that are certainly highlighted by the text. As for TM363? We’ve still got to figure all that out.